# About Hats Network





<Callout type="info" title="AS203314 - Global BGP Backbone">
  Hats Network Inc. operates a **global BGP backbone** with Points of Presence (PoPs) across Asia, Europe, and the Americas. We are dedicated to building a safer and more advanced next-generation network infrastructure.

  * **Founded:** 16 Aug 2022
  * **ASN:** AS203314
  * **Peering Policy:** Open Peering
  * **Network Type:** Eyeball ISP & Transit Provider
  * **Global PoPs:** 16+ across 4 continents
  * **Backbone Capacity:** 1 Tbps+ aggregated
  * **Upstream Providers:** Cogent (AS174), NTT (AS2914), Hurricane Electric (AS6939), PCCW Global (AS3491), iFog (AS34927)
</Callout>

Our Vision [#our-vision]

We imagine a world where network connectivity is seamless, secure and accessible to everyone. Our mission is to:

1. **Build** a robust, global BGP backbone with redundant infrastructure
2. **Enable** open peering and interconnection to improve Internet resilience
3. **Deliver** reliable IP-Transit services with transparent pricing
4. **Innovate** continuously to meet the demands of a rapidly evolving digital world

Network Resources [#network-resources]

<Cards>
  <Card title="Global PoP Map" icon="<IconMapPins className=&#x22;w-5 h-5&#x22; />" className="cursor-alias" description="View our interactive global network map and Points of Presence locations across Asia, Europe, and the Americas." href="/#network" external="true" />

  <Card title="GeoFeed" icon="<IconFileText className=&#x22;w-5 h-5&#x22; />" className="cursor-alias" description="Subscribe to our Geographic Feed (RFC 8805) for the latest updates on IP geographical mappings." href="https://hatsnet.io/geofeed/all.csv" external="true" />

  <Card title="PeeringDB" icon="<IconUsers className=&#x22;w-5 h-5&#x22; />" className="cursor-alias" description="View our complete peering information, including IX participation and contact details." href="https://www.peeringdb.com/asn/203314" external="true" />

  <Card title="BGP Tools" icon="<IconGlobe className=&#x22;w-5 h-5&#x22; />" className="cursor-alias" description="Explore our routing information, prefixes, and ASN connectivity on BGP.tools." href="https://bgp.tools/as/203314" external="true" />
</Cards>

<div id="global-presence" className="scroll-mt-24" />

Global Presence [#global-presence]

<NetworkMap />

<Callout type="default">
  Our network spans **16+ PoPs** across **4 continents**, providing low-latency connectivity and diverse routing options. Key backbone routes include **HKG ↔ TPE at 15 ms**, **AMS ↔ FRA at 5 ms**, **IAD ↔ NYC at 6 ms**, and **SIN ↔ MEL at 89 ms**.
</Callout>

Core Locations [#core-locations]

| Region      | City      | IATA           | Capacity | IX Exchanges                     | Status |
| ----------- | --------- | -------------- | -------- | -------------------------------- | ------ |
| Hong Kong   | Hong Kong | HKG1/HKG2/HKG3 | 50 Gbps  | Equinix HK, HKIX                 | Active |
| Japan       | Tokyo     | TYO2           | 100 Gbps | Equinix Tokyo, JPIX, BBIX, JPNAP | Active |
| Singapore   | Singapore | SIN1           | 200 Gbps | Equinix SG, SGIX                 | Active |
| Netherlands | Amsterdam | AMS            | 40 Gbps  | AMS-IX, NL-IX                    | Active |
| Germany     | Frankfurt | FRA            | 100 Gbps | DE-CIX Frankfurt                 | Active |
| UK          | London    | LON            | 100 Gbps | LINX                             | Active |

Edge Locations [#edge-locations]

| Region       | City         | IATA      | Capacity | IX Exchanges           | Status  |
| ------------ | ------------ | --------- | -------- | ---------------------- | ------- |
| Taiwan       | Taipei       | TPE1/TPE2 | 20 Gbps  | STUIX, TPIX-TW, TWIX   | Active  |
| Germany      | Berlin       | BER       | —        | DE-CIX, BCIX           | Active  |
| France       | Marseille    | MRS       | 80 Gbps  | France-IX              | Active  |
| USA          | Los Angeles  | LAX       | 100 Gbps | SFMIX                  | Active  |
| USA          | Ashburn      | IAD       | —        | —                      | Active  |
| USA          | New York     | NYC       | 150 Gbps | NYIIX, DE-CIX New York | Active  |
| USA          | Seattle      | SEA       | 100 Gbps | SIX Seattle            | Active  |
| Australia    | Melbourne    | MEL       | —        | HE / Superloop         | Active  |
| South Africa | Johannesburg | JNB       | —        | HE Only                | Planned |
| Brazil       | São Paulo    | GRU       | —        | NTT / Ascenty          | Planned |

Backbone Latency Matrix [#backbone-latency-matrix]

Key routes (representative sample, updated periodically):

| Route                   | RTT (ms) | Region Pair    |
| ----------------------- | -------- | -------------- |
| Hong Kong → Taipei      | \~15     | Intra-Asia     |
| Hong Kong → Singapore   | \~32     | Intra-Asia     |
| Amsterdam → Frankfurt   | \~5      | Intra-Europe   |
| Amsterdam → London      | \~6      | Intra-Europe   |
| Ashburn → New York      | \~6      | Intra-NorthAm  |
| New York → London       | \~92     | Trans-Atlantic |
| Hong Kong → Los Angeles | \~145    | Trans-Pacific  |
| Singapore → Melbourne   | \~89     | Asia-Oceania   |

For the full auto-updated RTT matrix across all 18 PoPs, see the [Backbone Latency Matrix](/docs/network/latency) page.

Featured Market Notes [#featured-market-notes]

<div id="pop-lax" className="scroll-mt-24" />

Los Angeles (LAX) [#los-angeles-lax]

Los Angeles is one of our primary west-coast handoff markets for trans-Pacific reach, bridging Asia-facing capacity into dense North American carrier ecosystems. Measured latency: **\~145 ms to HKG*&#x2A;, **\~101 ms to TYO*&#x2A;, **\~26 ms to SEA**, connected via SFMIX with 100 Gbps committed capacity.

<div id="pop-nyc" className="scroll-mt-24" />

New York (NYC) [#new-york-nyc]

New York represents our east-coast financial and transatlantic market focus, where low-latency delivery and backbone diversity matter most for enterprise-grade traffic profiles. Measured latency: **\~92 ms to LON*&#x2A; (trans-Atlantic), **\~57 ms to LAX*&#x2A; (cross-continental), **\~6 ms to IAD** (metro), with 150 Gbps committed capacity and NYIIX + DE-CIX New York peering.

<div id="pop-sea" className="scroll-mt-24" />

Seattle (SEA) [#seattle-sea]

Seattle serves as our Pacific Northwest gateway with exceptionally low latency to East Asia. Measured latency: **\~85 ms to TYO*&#x2A;, **\~115 ms to TPE*&#x2A;, **\~130 ms to HKG**, connected via SIX Seattle with 100 Gbps committed capacity and upstream providers HE, Cogent.

<div id="pop-mrs" className="scroll-mt-24" />

Marseille (MRS) [#marseille-mrs]

Marseille is a strategic Mediterranean cable landing market that strengthens south-European access to EMEA and subsea routes between east and west. Measured latency: **\~14 ms to FRA*&#x2A;, **\~21 ms to BER*&#x2A;, **\~26 ms to LON**, connected via France-IX with 80 Gbps committed capacity.

<div id="pop-mel" className="scroll-mt-24" />

Melbourne (MEL) [#melbourne-mel]

Melbourne provides our Oceania foothold, connecting Australia to our Asia-Pacific backbone via Singapore. Measured latency: **\~89 ms to SIN*&#x2A;, **\~114 ms to TYO*&#x2A;, **\~138 ms to HKG**, via HE and Superloop upstream connectivity.

Contact Us [#contact-us]

<Callout type="info" title="Need Help?">
  If you have any questions, peering requests, or abuse concerns, please feel free to reach out to the appropriate team below.
</Callout>

Contact Information [#contact-information]

| Team        | Email Address                                   | Purpose                              |
| ----------- | ----------------------------------------------- | ------------------------------------ |
| **Sales**   | [sales@hatsnet.io](mailto:sales@hatsnet.io)     | IP-Transit orders, pricing inquiries |
| **Peering** | [peering@hatsnet.io](mailto:peering@hatsnet.io) | Peering requests, PNI arrangements   |
| **NOC**     | [noc@hatsnet.io](mailto:noc@hatsnet.io)         | Network issues, outages              |
| **Support** | [support@hatsnet.io](mailto:support@hatsnet.io) | Abuse reports, general support       |

Quick Links [#quick-links]

<Cards>
  <Card title="Peering Policy" icon="<IconNetwork className=&#x22;w-5 h-5&#x22; />" description="Learn about our open peering policy and how to establish a session with AS203314." href="/docs/peering" />

  <Card title="IP Transit" icon="<IconServer className=&#x22;w-5 h-5&#x22; />" description="Explore our IP-Transit services in Asia and Europe." href="/docs/transit" />

  <Card title="BGP Communities" icon="<IconBuildingBroadcastTower className=&#x22;w-5 h-5&#x22; />" description="View our BGP community strings for route management." href="/docs/community" />
</Cards>


# Quick Start Guide





<Callout type="info" title="Hats Network Inc. (AS203314)">
  Hats Network operates a global BGP backbone focused on building next-generation network infrastructure. We provide IP transit, peering, and specialized routing services across Asia, Europe, and the Americas.
</Callout>

Our documentation covers network architecture, peering policies, transit services, and technical resources for network operators.

<Cards>
  <Card title="About Hats Network" description="Company overview, PoP locations, geofeed, and contact information." href="/docs/about" />

  <Card title="Our Services" description="Enterprise private networks, dedicated lines, premium user access, and performance routing profiles." href="/docs/services" />

  <Card title="Getting Peering ➡️" description="Open peering policy, IX presence, and peering coordinates." href="/docs/peering" />

  <Card title="Getting IP-Transit ➡️" description="Transit availability, pricing, and service coverage." href="/docs/transit" />

  <Card title="BGP Communities Reference" description="Community strings for route control and traffic engineering." href="/docs/community" />

  <Card title="Need to Report Abuse?" description="Please report any violations by our end-users, including DMCA, SPAM, DDoS attacks and other such activities." href="/docs/legal/report-abuse" />
</Cards>

Documentation Map [#documentation-map]

<Infographic
  code="infographic hierarchy-mindmap-branch-gradient-capsule-item
width 980
height 680
data
  title Documentation Map
  desc Start with company context, then branch into services, peering, transit, routing controls, and policy documents.
  root
    label Hats Network Docs
    children
      - label About
        icon info
        children
          - label Company Overview
          - label Global PoPs
          - label Contact Info
      - label Services
        icon wrench
        children
          - label EPN
            desc Enterprise Private Network
          - label BDL
            desc Business Dedicated Line
          - label PUL
            desc Premium User Line
          - label GO
            desc Gaming Optimized
          - label SR
            desc Streaming Ready
      - label Peering
        icon handshake
        children
          - label IX Peering
          - label Private PNI
          - label Tunnel Methods
      - label Transit
        icon globe
        children
          - label Asia Transit
          - label Europe Transit
      - label BGP Communities
        icon settings
        children
          - label Internal Tags
          - label Control Actions
          - label Reference Codes
      - label Legal
        icon clipboard
        children
          - label IP Rental
          - label Privacy Policy
          - label ToS / Abuse
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020 #5c6f82"
/>


# Control BGP Communities





Control communities allow you to **dictate prefix announcements** and manipulate path attributes dynamically. Attach these communities to routes you announce to AS203314 to control how we propagate them.

<Callout type="warning" title="Traffic Engineering">
  These communities give you fine-grained control over route propagation and path prepending outside Hats Network.
</Callout>

Blackhole & Filtering [#blackhole--filtering]

| Community      | Action                                 |
| -------------- | -------------------------------------- |
| `203314:0:666` | Do not announce this route (blackhole) |

**Usage**: Stop announcement of a prefix (e.g., during DDoS mitigation or IP address deprecation).

**Note**: Equivalent to standard blackhole community `65535:65281`.

Propagation Control [#propagation-control]

Control which types of peers receive your routes:

| Community    | Action                    |
| ------------ | ------------------------- |
| `203314:1:0` | Do not send to Upstream   |
| `203314:1:1` | Do not send to Peering    |
| `203314:1:2` | Do not send to Downstream |

<Callout type="info">
  **Example Use Cases**:

  * Use `203314:1:0` to prevent transit from carrying your prefix
  * Use `203314:1:1` to keep traffic limited to IX route servers
  * Use `203314:1:2` to prevent customer leakage
</Callout>

Geographic Restrictions [#geographic-restrictions]

Control route propagation based on location:

<Tabs defaultValue="regional" className="mt-6">
  <TabsList>
    <TabsTrigger value="regional">
      <Globe />

      Regional
    </TabsTrigger>

    <TabsTrigger value="pop">
      <MapPin />

      PoP-Specific
    </TabsTrigger>
  </TabsList>

  <TabsContent value="regional" className="space-y-3">
    | Community       | Action                                              |
    | --------------- | --------------------------------------------------- |
    | `203314:2:1`    | Do not send to other regions (Disable Cross Region) |
    | `203314:2:2`    | Do not send to other PoPs (Disable Cross PoP)       |
    | `203314:201:XX` | Do not send to Region `XX`                          |

    **Examples**:

    ```text
    # Keep traffic within Asia only
    203314:2:1         # Disable cross-region
    203314:201:300     # Exclude North America
    203314:201:200     # Exclude Europe
    ```
  </TabsContent>

  <TabsContent value="pop" className="space-y-3">
    | Community        | Action                   |
    | ---------------- | ------------------------ |
    | `203314:202:XXX` | Do not send to PoP `XXX` |

    **Examples**:

    ```text
    # Exclude specific PoPs
    203314:202:301     # Do not announce via Seattle
    203314:202:131     # Do not announce via Tokyo
    203314:202:102     # Do not announce via Hong Kong HKG2
    ```
  </TabsContent>
</Tabs>

Path Prepending [#path-prepending]

Control AS-path prepending for routes **outside** Hats Network:

<Callout type="info">
  **Scope**: Path prepending only affects routes announced to external peers (upstream, peering, customers)-not internal routing.
</Callout>

| Community      | Action                          |
| -------------- | ------------------------------- |
| `203314:220:1` | Prepend 1x outside Hats Network |
| `203314:220:2` | Prepend 2x outside Hats Network |
| `203314:220:3` | Prepend 3x outside Hats Network |
| `203314:220:4` | Prepend 4x outside Hats Network |
| `203314:220:5` | Prepend 5x outside Hats Network |

**Usage**: Deprioritize specific prefixes for inbound traffic engineering.

Community Decision Flow [#community-decision-flow]

<Infographic
  code="infographic sequence-ascending-steps
width 960
height 400
data
  title Community Decision Flow
  desc Match the routing goal to the right AS203314 control-community family before you announce the prefix.
  sequences
    - label Announce Route
      desc Start with the prefix you want AS203314 to propagate
      icon megaphone
    - label Pick a Policy
      desc Decide whether you need local-only propagation, prepending, PoP exclusion, or peer-type filtering
      icon list-filter
    - label Apply Communities
      desc Add the matching 203314:* tags to the route update you send us
      icon tag
    - label Announce to AS203314
      desc Our edge routers ingest the route and evaluate the attached controls
      icon router
    - label Verify the Effect
      desc Check route servers and looking glasses to confirm the intended propagation outcome
      icon check-circle
  order asc
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

Usage Examples [#usage-examples]

Example 1: Local Traffic Only [#example-1-local-traffic-only]

Announce a prefix only within a specific region:

```text
# Announce to Asia West only
203314:2:1         # Disable cross-region
```

Example 2: Deprioritize Backup Prefix [#example-2-deprioritize-backup-prefix]

Make a backup prefix less attractive:

```text
# Deprioritize via path prepending
203314:220:3      # Prepend 3x AS203314
```

Example 3: Selective Peering [#example-3-selective-peering]

Announce only to specific peer types:

```text
# Announce to peering and customers only
203314:1:0        # Do not send to upstream
```

Example 4: Exclude Location [#example-4-exclude-location]

Prevent announcement via specific location:

```text
# Exclude PoP-specific announcement
203314:202:301    # Do not send via Seattle
```

Example 5: Combined Control [#example-5-combined-control]

Combine multiple communities for complex policies:

```text
# Deprioritized, Asia-only, no upstream
203314:1:0        # No upstream
203314:2:1         # Asia only
203314:220:2      # Prepend 2x
```

Implementation Notes [#implementation-notes]

<Callout type="tip">
  **Best Practices**:

  1. **Test before production**: Use `203314:220:1` (1x prepend) to verify communities work
  2. **Monitor impact**: Check route servers and looking glasses after applying changes
  3. **Document your policies**: Keep track of which prefixes use which communities
  4. **Use conservative prepends**: 3x prepend is usually sufficient; 5x is extreme
</Callout>

Configuration Examples (JunOS / BIRD2) [#configuration-examples-junos--bird2]

AS203314 communities are **BGP Large Communities** (RFC 8092). On JunOS they are written with the
`large:` prefix (for example `large:203314:0:666`). In BIRD2 they are handled via
`bgp_large_community` with `(203314, 0, 666)` tuples.

<Callout type="warning" title="Export Policy Safety Default (Strongly Recommended)">
  The BIRD2 examples below are **export policies**. The default action should be `reject;` to prevent
  route leaks if someone copy-pastes into production.\
  For JunOS, it's also recommended to add a final `term REJECT-ALL then reject` as a safety catch-all.
</Callout>

<Tabs defaultValue="junos" className="mt-6">
  <TabsList>
    <TabsTrigger value="junos">
      <Terminal />

      JunOS
    </TabsTrigger>

    <TabsTrigger value="bird2">
      <Feather />

      BIRD2
    </TabsTrigger>
  </TabsList>

  <TabsContent value="junos" className="space-y-6">
    **Example: Blackhole (`203314:0:666`)**

    ```bash
    set policy-options community HATS-BLACKHOLE members large:203314:0:666

    set policy-options policy-statement EXPORT-TO-HATS term BLACKHOLE from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term BLACKHOLE then community add HATS-BLACKHOLE
    set policy-options policy-statement EXPORT-TO-HATS term BLACKHOLE then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```

    **Example: No Upstream (`203314:1:0`) + Prepend 3x (`203314:220:3`)**

    ```bash
    set policy-options community HATS-NO-UPSTREAM members large:203314:1:0
    set policy-options community HATS-PREPEND-3X members large:203314:220:3

    set policy-options policy-statement EXPORT-TO-HATS term BACKUP from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term BACKUP then community add [ HATS-NO-UPSTREAM HATS-PREPEND-3X ]
    set policy-options policy-statement EXPORT-TO-HATS term BACKUP then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```

    **Example: Keep in-region + Exclude a PoP (`203314:2:1` + `203314:202:253`)**

    ```bash
    set policy-options community HATS-NO-CROSS-REGION members large:203314:2:1
    set policy-options community HATS-NO-AMS members large:203314:202:253

    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-ONLY from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-ONLY then community add [ HATS-NO-CROSS-REGION HATS-NO-AMS ]
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-ONLY then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```
  </TabsContent>

  <TabsContent value="bird2" className="space-y-6">
    **Example: Blackhole (`203314:0:666`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 0, 666));
        accept;
      }
      reject; # Safety default
    }
    ```

    **Example: No Upstream (`203314:1:0`) + Prepend 3x (`203314:220:3`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 1, 0));
        bgp_large_community.add((203314, 220, 3));
        accept;
      }
      reject; # Safety default
    }
    ```

    **Example: Keep in-region + Exclude a PoP (`203314:2:1` + `203314:202:253`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 2, 1));
        bgp_large_community.add((203314, 202, 253));
        accept;
      }
      reject; # Safety default
    }
    ```
  </TabsContent>
</Tabs>

Related Information [#related-information]

* **[PoP Codes](/docs/community/pop-codes)** - Reference for PoP numbers (XXX) in geographic restrictions
* **[Region Codes](/docs/community/region-codes)** - Reference for region numbers (XX) in geographic restrictions
* **[Internal Communities](/docs/community/internal-communities)** - Communities we attach to routes we announce

<Callout type="warning">
  **Important**: Control communities are applied to routes **you announce to AS203314**. They do not affect routes we announce to you.
</Callout>


# BGP Communities





<Callout type="info" title="AS203314 BGP Communities">
  Hats Network (AS203314) uses a **comprehensive BGP community structure** to help network operators manage their routing policies effectively.
</Callout>

Community System Overview [#community-system-overview]

<Infographic
  code="infographic hierarchy-structure
width 980
height 720
data
  title AS203314 Community System
  desc The community space is split into route-origin signals, policy controls, and reference codebooks for PoPs and regions.
  items
    - label Internal Signals
      children
        - label Route Origin 110
          children
            - label Upstream 10
            - label Downstream 20
            - label Peering 30
            - label Hats Origin 110
        - label PoP Scope
          children
            - label Learned At 120
              desc Entry PoP code
            - label Passed Through 125
              desc Transit PoP code
        - label Region Scope
          children
            - label Learned In 130
              desc Entry region code
            - label Passed Through 135
              desc Transit region code
    - label Control Actions
      children
        - label Blackhole / Filtering
          children
            - label 203314:0:666
              desc Do not announce
        - label Propagation Control
          children
            - label 203314:1:0
              desc No upstream
            - label 203314:1:1
              desc No peering
            - label 203314:1:2
              desc No downstream
        - label Geographic Restrictions
          children
            - label 203314:2:1
              desc No cross-region
            - label 203314:2:2
              desc No cross-PoP
            - label 203314:201:XX
              desc Exclude region
            - label 203314:202:XXX
              desc Exclude PoP
        - label AS-Path Prepend
          children
            - label 203314:220:1~5
              desc Prepend 1x to 5x
    - label Reference Codes
      children
        - label PoP Codes
          children
            - label XXX format
              desc 3-digit codes (101-451)
        - label Region Codes
          children
            - label XX format
              desc 2-digit codes (100-500)
theme light

palette antv"
/>

Quick Reference [#quick-reference]

| Category            | Community        | Purpose                   | Details                                                                               |
| ------------------- | ---------------- | ------------------------- | ------------------------------------------------------------------------------------- |
| **Origin**          | `203314:110:XX`  | Route source type         | [See Origin →](/docs/community/internal-communities#route-origin)                     |
| **PoP**             | `203314:120:XXX` | Learned at PoP            | [See PoP-Based →](/docs/community/internal-communities#pop-based-communities)         |
| **PoP Pass**        | `203314:125:XXX` | Passed through PoP        | [See PoP-Based →](/docs/community/internal-communities#pop-based-communities)         |
| **Region**          | `203314:130:XX`  | Learned in region         | [See Region-Based →](/docs/community/internal-communities#region-based-communities)   |
| **Region Pass**     | `203314:135:XX`  | Passed through region     | [See Region-Based →](/docs/community/internal-communities#region-based-communities)   |
| **Blackhole**       | `203314:0:666`   | Do not announce           | [See Blackhole →](/docs/community/control-communities#blackhole--filtering)           |
| **No Upstream**     | `203314:1:0`     | Do not send to upstream   | [See Propagation →](/docs/community/control-communities#propagation-control)          |
| **No Peering**      | `203314:1:1`     | Do not send to peering    | [See Propagation →](/docs/community/control-communities#propagation-control)          |
| **No Customer**     | `203314:1:2`     | Do not send to downstream | [See Propagation →](/docs/community/control-communities#propagation-control)          |
| **No Cross-Region** | `203314:2:1`     | Keep within region        | [See Geo Restrictions →](/docs/community/control-communities#geographic-restrictions) |
| **No Cross-PoP**    | `203314:2:2`     | Keep within PoP           | [See Geo Restrictions →](/docs/community/control-communities#geographic-restrictions) |
| **No Region**       | `203314:201:XX`  | Exclude region            | [See Geo Restrictions →](/docs/community/control-communities#geographic-restrictions) |
| **No PoP**          | `203314:202:XXX` | Exclude PoP               | [See Geo Restrictions →](/docs/community/control-communities#geographic-restrictions) |
| **Prepend 1x**      | `203314:220:1`   | Prepend AS 1 time         | [See Path Prepending →](/docs/community/control-communities#path-prepending)          |
| **Prepend 2x**      | `203314:220:2`   | Prepend AS 2 times        | [See Path Prepending →](/docs/community/control-communities#path-prepending)          |
| **Prepend 3x**      | `203314:220:3`   | Prepend AS 3 times        | [See Path Prepending →](/docs/community/control-communities#path-prepending)          |
| **Prepend 4x**      | `203314:220:4`   | Prepend AS 4 times        | [See Path Prepending →](/docs/community/control-communities#path-prepending)          |
| **Prepend 5x**      | `203314:220:5`   | Prepend AS 5 times        | [See Path Prepending →](/docs/community/control-communities#path-prepending)          |

Community Categories [#community-categories]

<Cards>
  <Card title="Internal Communities" icon="<IconBuildingBroadcastTower className=&#x22;w-5 h-5&#x22; />" description="Route origin types, PoP locations, and region codes for identifying where routes are learned." href="/docs/community/internal-communities" />

  <Card title="Control Communities" icon="<IconSettings className=&#x22;w-5 h-5&#x22; />" description="Traffic engineering communities for blackhole, propagation control, and path prepending." href="/docs/community/control-communities" />

  <Card title="PoP Codes" icon="<IconMap className=&#x22;w-5 h-5&#x22; />" description="3-digit codes for each Point of Presence used in location-based communities." href="/docs/community/pop-codes" />

  <Card title="Region Codes" icon="<IconMap className=&#x22;w-5 h-5&#x22; />" description="2-digit geographic region codes for area-based routing policies." href="/docs/community/region-codes" />
</Cards>

Usage Examples [#usage-examples]

<Callout type="tip">
  Common Scenarios [#common-scenarios]

  * Keep traffic local:

  ```bird2
  bgp_large_community.add((203314, 2, 1)); # Do not send to other regions
  ```

  * Deprioritize upstream:

  ```bird2
  bgp_large_community.add((203314, 220, 3)); # Prepend 3x to upstream routes
  ```

  * Exclude specific PoP:

  ```bird2
  bgp_large_community.add((203314, 202, 253)); # Do not send to AMS
  ```
</Callout>

Configuration Examples (JunOS / BIRD2) [#configuration-examples-junos--bird2]

Below are minimal snippets showing how to **attach AS203314 large communities** to the prefixes you
announce to us.

<Callout type="warning" title="Export Policy Safety Default (Strongly Recommended)">
  These snippets are **export policies**. For BIRD2, use `reject;` as the default action to prevent
  route leaks.\
  For JunOS, add a final `term REJECT-ALL then reject` as a safety catch-all.
</Callout>

<Callout type="info" title="Documentation Prefixes">
  These examples use documentation-only prefixes from RFC 5737 / RFC 3849 (e.g. `203.0.113.0/24`,
  `2001:db8::/32`). Replace them with your real announced prefixes.
</Callout>

<Tabs defaultValue="junos" className="mt-6">
  <TabsList>
    <TabsTrigger value="junos">
      <Terminal />

      JunOS
    </TabsTrigger>

    <TabsTrigger value="bird2">
      <Feather />

      BIRD2
    </TabsTrigger>
  </TabsList>

  <TabsContent value="junos" className="space-y-6">
    **Keep traffic local (`203314:2:1`)**

    ```bash
    set policy-options community HATS-NO-CROSS-REGION members large:203314:2:1

    set policy-options policy-statement EXPORT-TO-HATS term LOCAL from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL then community add HATS-NO-CROSS-REGION
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```

    **Deprioritize a backup prefix (`203314:220:3`)**

    ```bash
    set policy-options community HATS-PREPEND-3X members large:203314:220:3

    set policy-options policy-statement EXPORT-TO-HATS term BACKUP from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term BACKUP then community add HATS-PREPEND-3X
    set policy-options policy-statement EXPORT-TO-HATS term BACKUP then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```

    **IPv6 variant**

    ```bash
    set policy-options community HATS-NO-CROSS-REGION members large:203314:2:1

    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-V6 from route-filter 2001:db8:203:113::/48 exact
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-V6 then community add HATS-NO-CROSS-REGION
    set policy-options policy-statement EXPORT-TO-HATS term LOCAL-V6 then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```
  </TabsContent>

  <TabsContent value="bird2" className="space-y-6">
    **Keep traffic local (`203314:2:1`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 2, 1));
        accept;
      }
      reject; # Safety default
    }
    ```

    **Deprioritize a backup prefix (`203314:220:3`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 220, 3));
        accept;
      }
      reject; # Safety default
    }
    ```

    **IPv6 variant**

    ```bird2
    filter export_to_hats_v6 {
      if net = 2001:db8:203:113::/48 then {
        bgp_large_community.add((203314, 2, 1));
        accept;
      }
      reject; # Safety default
    }
    ```
  </TabsContent>
</Tabs>

<Infographic
  code="infographic sequence-ascending-steps
width 980
height 480
data
  title Common Community Workflow
  desc Operators identify routing goals, then apply the minimal community set to shape propagation effectively.
  sequences
    - label Read Route
      desc Check origin, locality, or policy needs
      icon eye
    - label Pick Family
      desc Internal tags for analysis, control for shaping
      icon search
    - label Apply Tags
      desc Announce with only needed communities
      icon plus
    - label Verify
      desc Check export scope and path changes
      icon check-circle
  order asc
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

Related Resources [#related-resources]

<Cards>
  <Card title="Peering Policy" icon="<IconNetwork className=&#x22;w-5 h-5&#x22; />" description="Learn how to establish BGP peering with AS203314." href="/docs/peering" />

  <Card title="IP Transit" icon="<IconServer className=&#x22;w-5 h-5&#x22; />" description="Get IP-Transit with BGP community support." href="/docs/transit" />
</Cards>


# Internal BGP Communities





Internal communities indicate **where routes are learned from** and whether they are uniquely announced. These communities help you identify the source and path of routes received from AS203314.

<Callout type="info">
  **Community Format:** `203314:XXX:YY` where `XXX` is the category and `YY` is the specific value.
</Callout>

Route Origin [#route-origin]

These communities indicate **how** a route was learned by Hats Network:

| Community        | Description                          | Unique |
| ---------------- | ------------------------------------ | ------ |
| `203314:110:10`  | Route learned from Upstream          | Yes    |
| `203314:110:20`  | Route learned from Downstream        | Yes    |
| `203314:110:30`  | Route learned from Peering           | Yes    |
| `203314:110:110` | Route originated within Hats Network | Yes    |

**Unique** means this route is only announced via this method-if you see `203314:110:30`, the route is exclusively available via peering.

PoP-Based Communities [#pop-based-communities]

These communities identify **which PoP** a route was learned at or passed through:

<Tabs defaultValue="learned" className="mt-6">
  <TabsList>
    <TabsTrigger value="learned">
      <MapPin />

      Learned At
    </TabsTrigger>

    <TabsTrigger value="passed">
      <Route />

      Passed Through
    </TabsTrigger>
  </TabsList>

  <TabsContent value="learned" className="space-y-3">
    Routes learned **at** a specific PoP (entry point):

    | Community        | Description                | Unique |
    | ---------------- | -------------------------- | ------ |
    | `203314:120:XXX` | Route learned at PoP `XXX` | Yes    |

    **Example**: `203314:120:101` means the route was learned at Hong Kong (HKG1).
  </TabsContent>

  <TabsContent value="passed" className="space-y-3">
    Routes that **passed through** a PoP (transit):

    | Community        | Description                    | Unique |
    | ---------------- | ------------------------------ | ------ |
    | `203314:125:XXX` | Route passed through PoP `XXX` | No     |

    **Example**: `203314:125:101` means the route passed through Hong Kong (HKG1).
  </TabsContent>
</Tabs>

Region-Based Communities [#region-based-communities]

These communities identify **which region** a route was learned in or passed through:

<Tabs defaultValue="learned" className="mt-6">
  <TabsList>
    <TabsTrigger value="learned">
      <Globe />

      Learned In
    </TabsTrigger>

    <TabsTrigger value="passed">
      <Route />

      Passed Through
    </TabsTrigger>
  </TabsList>

  <TabsContent value="learned" className="space-y-3">
    Routes learned **within** a specific region:

    | Community       | Description                  | Unique |
    | --------------- | ---------------------------- | ------ |
    | `203314:130:XX` | Route learned in Region `XX` | Yes    |

    **Example**: `203314:130:100` means the route was learned in Asia (West).
  </TabsContent>

  <TabsContent value="passed" className="space-y-3">
    Routes that **passed through** a region:

    | Community       | Description                      | Unique |
    | --------------- | -------------------------------- | ------ |
    | `203314:135:XX` | Route passed through Region `XX` | No     |

    **Example**: `203314:135:100` means the route passed through Asia (West).
  </TabsContent>
</Tabs>

Usage Examples [#usage-examples]

Identify Route Source [#identify-route-source]

Determine if a route comes from peering, upstream, or our customers:

```bird2
# These large communities are attached by AS203314 on routes you receive.
# You typically match them in your import policy:
filter import_prefer_peering_v4 {
  if (203314, 110, 30) ~ bgp_large_community then bgp_local_pref = 200; # prefer peering-learned routes
  if (203314, 110, 10) ~ bgp_large_community then bgp_local_pref = 80; # de-prioritize upstream-learned routes
  accept;
}
```

Identify Entry Location [#identify-entry-location]

Determine where a route entered our network:

```bird2
filter import_prefer_asia_pops_v4 {
  if (203314, 120, 101) ~ bgp_large_community then bgp_local_pref = 200; # entered at HKG1 (Hong Kong)
  if (203314, 120, 131) ~ bgp_large_community then bgp_local_pref = 180; # entered at TYO2 (Tokyo)
  accept;
}
```

Filter by Region [#filter-by-region]

Accept routes only from specific regions:

```bird2
# Only accept routes learned in Asia West
filter import_only_asia_west_v4 {
  if (203314, 130, 100) ~ bgp_large_community then accept;
  reject;
}

# Reject routes that passed through Europe (both West=200 and East=250)
filter import_reject_europe_transit_v4 {
  if (203314, 135, 200) ~ bgp_large_community then reject;
  if (203314, 135, 250) ~ bgp_large_community then reject;
  accept;
}
```

Policy Examples (JunOS / BIRD2) [#policy-examples-junos--bird2]

Internal communities are also **BGP Large Communities**. You can match them in your import policy
to influence local preference, selection, or filtering.

<Tabs defaultValue="junos" className="mt-6">
  <TabsList>
    <TabsTrigger value="junos">
      <Terminal />

      JunOS
    </TabsTrigger>

    <TabsTrigger value="bird2">
      <Feather />

      BIRD2
    </TabsTrigger>
  </TabsList>

  <TabsContent value="junos" className="space-y-6">
    **Prefer routes learned in Asia West (`203314:130:100`)**

    ```bash
    set policy-options community HATS-REGION-ASIA-W members large:203314:130:100

    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W from community HATS-REGION-ASIA-W
    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W then local-preference 200
    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W then accept
    ```

    **Reject routes learned from Upstream (`203314:110:10`)**

    ```bash
    set policy-options community HATS-ORIGIN-UPSTREAM members large:203314:110:10

    set policy-options policy-statement IMPORT-FROM-HATS term NO-UPSTREAM from community HATS-ORIGIN-UPSTREAM
    set policy-options policy-statement IMPORT-FROM-HATS term NO-UPSTREAM then reject
    ```
  </TabsContent>

  <TabsContent value="bird2" className="space-y-6">
    **Prefer routes learned in Asia West (`203314:130:100`)**

    ```bird2
    filter import_from_hats_v4 {
      if (203314, 130, 100) ~ bgp_large_community then {
        bgp_local_pref = 200;
        accept;
      }
      accept;
    }
    ```

    **Reject routes learned from Upstream (`203314:110:10`)**

    ```bird2
    filter import_from_hats_v4 {
      if (203314, 110, 10) ~ bgp_large_community then reject;
      accept;
    }
    ```
  </TabsContent>
</Tabs>

Related Information [#related-information]

* **[PoP Codes](/docs/community/pop-codes)** - Reference for PoP numbers (XXX)
* **[Region Codes](/docs/community/region-codes)** - Reference for region numbers (XX)
* **[Control Communities](/docs/community/control-communities)** - Traffic engineering communities

<Callout type="tip">
  **Tip**: Internal communities are automatically attached to routes we announce to you. Use them to make informed routing decisions based on route origin and location.
</Callout>


# PoP Codes





Each Point of Presence (PoP) has a unique **3-digit code** used in community strings like `203314:120:XXX` and `203314:202:XXX`.

<Callout type="info">
  **Usage**: These codes identify specific PoP locations in internal communities (`120:XXX`, `125:XXX`) and control communities (`202:XXX`).
</Callout>

PoP Code Reference [#pop-code-reference]

| Location  | IATA | Generation | Type | PoP Code | Notes  |
| --------- | ---- | ---------- | ---- | -------- | ------ |
| Hong Kong | HKG1 | Gen2       | Core | 101      | Unique |
| Hong Kong | HKG2 | Gen2       | Core | 102      | Unique |
| Hong Kong | HKG3 | Gen2       | Core | 103      |        |
| Taiwan    | TPE1 | Gen2       | Core | 121      |        |
| Taiwan    | TPE2 | Gen2       | Core | 122      |        |
| Tokyo     | TYO1 | Gen2       | Edge | 111      |        |
| Tokyo     | TYO2 | Gen2       | Core | 131      | Unique |
| Singapore | SIN1 | Gen2       | Core | 151      | Unique |
| Seattle   | SEA  | Gen2       | Core | 301      |        |
| Ashburn   | IAD  | Gen2       | Core | 302      |        |
| San Jose  | SJC  | Gen2       | Edge | 303      |        |
| Moscow    | MOW  | Gen2       | Core | 201      |        |
| Frankfurt | FRA  | Gen2       | Edge | 252      |        |
| Zurich    | ZRH  | Gen2       | Edge | 251      |        |
| Amsterdam | AMS  | Gen2       | Edge | 253      |        |
| Berlin    | BER  | Gen2       | Edge | 254      | Unique |
| London    | LON  | Gen2       | Edge | 255      | Unique |
| Melbourne | MEL  | Gen2       | Edge | 451      |        |

Type Definitions [#type-definitions]

* **Core PoP**: Major interconnection points with multiple upstream providers
* **Edge PoP**: Smaller presence focused on local connectivity

Generation Definitions [#generation-definitions]

* **Gen2**: Second-generation infrastructure (current deployment)

Using PoP Codes [#using-pop-codes]

In Internal Communities [#in-internal-communities]

Identify where a route was learned:

```bird2
# Learned-at tags (set by AS203314 on routes you receive):
# (203314, 120, 101) -> HKG1 (Hong Kong)
# (203314, 120, 131) -> TYO2 (Tokyo)
# (203314, 120, 302) -> IAD (Ashburn)

filter prefer_hkg1_routes_v4 {
  if (203314, 120, 101) ~ bgp_large_community then bgp_local_pref = 200;
  accept;
}
```

In Control Communities [#in-control-communities]

Exclude specific PoPs from receiving announcements:

```bird2
bgp_large_community.add((203314, 202, 301)); # Do not announce via Seattle
bgp_large_community.add((203314, 202, 131)); # Do not announce via Tokyo
bgp_large_community.add((203314, 202, 102)); # Do not announce via HKG2
```

Configuration Snippets (JunOS / BIRD2) [#configuration-snippets-junos--bird2]

Use PoP codes in the control community `203314:202:XXX` to exclude specific locations. For example,
Amsterdam is `253`, so the large community is `203314:202:253`.

<Tabs defaultValue="junos" className="mt-6">
  <TabsList>
    <TabsTrigger value="junos">
      <Terminal />

      JunOS
    </TabsTrigger>

    <TabsTrigger value="bird2">
      <Feather />

      BIRD2
    </TabsTrigger>
  </TabsList>

  <TabsContent value="junos" className="space-y-3">
    ```bash
    set policy-options community HATS-NO-AMS members large:203314:202:253

    set policy-options policy-statement EXPORT-TO-HATS term NO-AMS from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term NO-AMS then community add HATS-NO-AMS
    set policy-options policy-statement EXPORT-TO-HATS term NO-AMS then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```
  </TabsContent>

  <TabsContent value="bird2" className="space-y-3">
    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 202, 253)); # no AMS
        accept;
      }
      reject; # Safety default
    }
    ```
  </TabsContent>
</Tabs>

Related Information [#related-information]

* **[Region Codes](/docs/community/region-codes)** - Geographic region groupings
* **[Internal Communities](/docs/community/internal-communities)** - Using PoP codes in location-based communities
* **[Control Communities](/docs/community/control-communities)** - Using PoP codes in traffic engineering

<Callout type="tip">
  **Tip**: PoP codes are primarily used for granular traffic engineering when you need to control route propagation at the location level.
</Callout>


# Region Codes





Regions are grouped by **geographic area** with 2-digit codes used in community strings like `203314:130:XX` and `203314:201:XX`.

<Callout type="info">
  **Usage**: These codes identify geographic regions in internal communities (`130:XX`, `135:XX`) and control communities (`201:XX`).
</Callout>

Region Code Reference [#region-code-reference]

| Region Name | Area  | Code | Notes                        |
| ----------- | ----- | ---- | ---------------------------- |
| Asia        | West  | 100  | Hong Kong, Taiwan            |
| Asia        | East  | 150  | Japan, Singapore             |
| Europe      | West  | 200  | UK, Ireland, France          |
| Europe      | East  | 250  | Germany, Netherlands, Russia |
| Americas    | North | 300  | USA, Canada                  |
| Americas    | South | 350  | Brazil, Argentina            |
| Australia   | West  | 400  | Perth                        |
| Australia   | East  | 450  | Melbourne, Sydney            |
| Antarctica  | -     | 500  | Research networks            |

Regional Groupings [#regional-groupings]

Asia (100, 150) [#asia-100-150]

**Asia West (100)**: Hong Kong, Taiwan, mainland China

**Asia East (150)**: Japan, Korea, Singapore, Southeast Asia

Europe (200, 250) [#europe-200-250]

**Europe West (200)**: UK, Ireland, France, Benelux, Iberia

**Europe East (250)**: Germany, DACH, Netherlands, Nordics, Eastern Europe

Americas (300, 350) [#americas-300-350]

**North America (300)**: United States, Canada, Mexico

**South America (350)**: Brazil, Argentina, Chile, Colombia

Oceania (400, 450) [#oceania-400-450]

**Australia West (400)**: Western Australia

**Australia East (450)**: Eastern states (NSW, VIC, QLD)

Using Region Codes [#using-region-codes]

In Internal Communities [#in-internal-communities]

Identify where a route was learned:

```bird2
# Learned-in tags (set by AS203314 on routes you receive):
# (203314, 130, 100) -> Asia West
# (203314, 130, 150) -> Asia East
# (203314, 130, 300) -> North America

filter prefer_asia_west_routes_v4 {
  if (203314, 130, 100) ~ bgp_large_community then bgp_local_pref = 200;
  accept;
}
```

In Control Communities [#in-control-communities]

Control geographic propagation:

```bird2
bgp_large_community.add((203314, 2, 1)); # Disable cross-region
bgp_large_community.add((203314, 201, 300)); # Exclude North America
bgp_large_community.add((203314, 201, 200)); # Exclude Europe
```

Configuration Snippets (JunOS / BIRD2) [#configuration-snippets-junos--bird2]

Region codes are used in large communities like `203314:201:XX` (exclude region) and
`203314:130:XX` (learned in region). Below are minimal examples you can adapt.

<Tabs defaultValue="junos" className="mt-6">
  <TabsList>
    <TabsTrigger value="junos">
      <Terminal />

      JunOS
    </TabsTrigger>

    <TabsTrigger value="bird2">
      <Feather />

      BIRD2
    </TabsTrigger>
  </TabsList>

  <TabsContent value="junos" className="space-y-6">
    **Exclude North America (`203314:201:300`)**

    ```bash
    set policy-options community HATS-NO-NA members large:203314:201:300

    set policy-options policy-statement EXPORT-TO-HATS term NO-NA from route-filter 203.0.113.0/24 exact
    set policy-options policy-statement EXPORT-TO-HATS term NO-NA then community add HATS-NO-NA
    set policy-options policy-statement EXPORT-TO-HATS term NO-NA then accept
    set policy-options policy-statement EXPORT-TO-HATS term REJECT-ALL then reject
    ```

    **Prefer routes learned in Asia West (`203314:130:100`)**

    ```bash
    set policy-options community HATS-ASIA-W members large:203314:130:100

    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W from community HATS-ASIA-W
    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W then local-preference 200
    set policy-options policy-statement IMPORT-FROM-HATS term ASIA-W then accept
    ```
  </TabsContent>

  <TabsContent value="bird2" className="space-y-6">
    **Exclude North America (`203314:201:300`)**

    ```bird2
    filter export_to_hats_v4 {
      if net = 203.0.113.0/24 then {
        bgp_large_community.add((203314, 201, 300));
        accept;
      }
      reject; # Safety default
    }
    ```

    **Prefer routes learned in Asia West (`203314:130:100`)**

    ```bird2
    filter import_from_hats_v4 {
      if (203314, 130, 100) ~ bgp_large_community then bgp_local_pref = 200;
      accept;
    }
    ```
  </TabsContent>
</Tabs>

Regional Filtering Examples [#regional-filtering-examples]

**Accept only Asian routes**:

```text
# Allow only Asia West and Asia East
if (community matches 203314:130:1*) then accept
else reject
```

**Prefer local region**:

```text
# Higher local preference for Asia West
if (community matches 203314:130:100) then localpref 200
if (community matches 203314:130:150) then localpref 150
if (community matches 203314:130:300) then localpref 100
```

Related Information [#related-information]

* **[PoP Codes](/docs/community/pop-codes)** - Specific location codes within regions
* **[Internal Communities](/docs/community/internal-communities)** - Using region codes in location-based communities
* **[Control Communities](/docs/community/control-communities)** - Using region codes in traffic engineering

<Callout type="tip">
  **Tip**: Region codes are ideal for high-level geographic traffic engineering when you don't need PoP-level granularity.
</Callout>


# IP Address Rental Terms







<Callout type="info">
  **Effective Date:** June 1, 2024\
  &#x2A;*Last Revised:** August 24, 2024
</Callout>

1\. Service Description [#1-service-description]

Our company provides IP address rental services. The lessee agrees to comply with all applicable laws, regulations, and these Terms of Service.

<Callout type="default" title="What is IP Rental?">
  IP Address Rental allows you to lease IPv4 or IPv6 addresses from Hats Network Inc. for your infrastructure needs. This service is ideal for:

  * Hosting providers requiring additional IP space
  * Research and development projects
  * Temporary network expansions
</Callout>

2\. Responsibilities and Penalties [#2-responsibilities-and-penalties]

Lessees are responsible for all activities associated with their rented IP address.

General Complaints [#general-complaints]

<Callout type="warn">
  **Penalty:** $5 per incident, maximum $20 per billing period
</Callout>

Including but not limited to:

* DMCA copyright complaints
* Spam complaints (unsolicited email)
* Unauthorized marketing activity complaints
* Minor service abuse complaints

Severe Misconduct [#severe-misconduct]

<Callout type="error">
  **Penalty:** $15 per incident, maximum $30 per billing period

  Severe misconduct carries heavier penalties and may lead to swift suspensions.
</Callout>

Including but not limited to:

* Network scanning activities (port scanning, vulnerability scanning)
* Spreading malware or viruses
* Participating in network attacks (DDoS, brute force)
* Unauthorized system intrusion attempts
* Phishing activities
* Hosting illegal content

IP Blacklisting [#ip-blacklisting]

<Callout type="error">
  **Penalty:** \$30 per incident OR 6-month service extension
</Callout>

IP addresses listed on major blacklists including:

| Blacklist             | Type                                |
| --------------------- | ----------------------------------- |
| Spamhaus              | Email reputation                    |
| DNSBL                 | DNS-based blacklist                 |
| SORBS                 | Spam and Open Relay Blocking System |
| SpamCop               | Spam reporting                      |
| Cisco Talos           | Security intelligence               |
| Microsoft SmartScreen | Email filtering                     |
| Google Safe Browsing  | Web safety                          |

3\. Payment and Penalty Enforcement [#3-payment-and-penalty-enforcement]

<Callout type="default">
  **Important:** All penalty fees will be added to the lessee's next invoice. Penalties take effect immediately upon notification. Failure to pay may result in service suspension or termination.
</Callout>

Payment Terms [#payment-terms]

* Invoices are issued monthly
* Payment is due within 14 days of invoice date
* Late payments subject to 1.5% monthly service charge
* All fees are non-refundable unless otherwise stated

4\. Service Termination [#4-service-termination]

<Callout type="error" title="Termination Policy">
  The company reserves the right to terminate services due to severe or repeated violations **without refund**.
</Callout>

Severe Violations Include: [#severe-violations-include]

* Multiple occurrences of severe misconduct
* Repeated IP blacklisting
* Engagement in illegal activities
* Non-payment of fees for 30+ days

Voluntary Termination: [#voluntary-termination]

Lessees may terminate service with 30 days written notice. No refunds for prepaid unused periods.

5\. Disclaimer [#5-disclaimer]

The company is not responsible for any losses or damages resulting from the lessee's use of the IP address. The lessee agrees to indemnify and hold the company harmless from any claims arising from their use of the service.

6\. Monitoring and Reporting [#6-monitoring-and-reporting]

<Callout type="info">
  The company has the right to monitor IP usage to ensure compliance with these terms. Lessees agree to promptly report any abuse or unauthorized use.
</Callout>

We monitor for:

* Unusual traffic patterns
* Blacklist status changes
* Abuse reports from third parties
* Compliance with AUP (Acceptable Use Policy)

7\. Amendment of Terms [#7-amendment-of-terms]

The company reserves the right to modify these Terms of Service at any time. Modified terms will be:

1. Posted on the company website
2. Emailed to the lessee's registered contact
3. Effective 30 days after posting

**Continued use implies acceptance of modified terms.**

8\. Notice of Changes [#8-notice-of-changes]

The company reserves the right to make changes to these terms without prior notice in cases of:

* Emergency security issues
* Legal or regulatory requirements
* Force majeure events

Questions? [#questions]

<Cards>
  <Card title="Contact Sales" icon="<IconMail className=&#x22;w-5 h-5&#x22; />" description="For questions about IP rental availability and pricing." href="mailto:sales@hatsnet.io" />

  <Card title="Contact Support" icon="<IconShieldCheck className=&#x22;w-5 h-5&#x22; />" description="For abuse reports or compliance questions." href="mailto:support@hatsnet.io" />
</Cards>

***

<Callout type="default">
  *By using this service, the lessee agrees to abide by these terms.*
</Callout>


# Privacy Policy





<Callout type="info">
  **Effective Date:** March 24, 2026\
  &#x2A;*Last Revised:** March 24, 2026
</Callout>

Introduction [#introduction]

Hats Network Inc. (AS203314) is committed to protecting your privacy and ensuring you have a positive experience on our website and while using our services.

This Privacy Policy explains how we collect, use, disclose, and safeguard your information when you visit our website and use our services.

<Callout type="default">
  Please read this Privacy Policy carefully. If you do not agree with our policies and practices, please do not use our services.
</Callout>

Information We Collect [#information-we-collect]

Information You Provide Directly [#information-you-provide-directly]

* Contact information (name, email, phone, company name) via contact forms
* Account information when you register for services
* Payment information processed securely through third-party providers
* Communication history and support inquiries

Information Collected Automatically [#information-collected-automatically]

* IP address and device information
* Browser type and operating system
* Pages visited, time spent, and referring URLs
* Network performance metrics and latency measurements
* Cookies and similar tracking technologies

How We Use Your Information [#how-we-use-your-information]

We use the information we collect for the following purposes:

* Provide, maintain, and improve our services
* Process transactions and send related information
* Send technical notices and support messages
* Respond to inquiries and customer support requests
* Monitor and analyze usage patterns and service performance
* Detect, prevent, and address technical issues and fraud
* Comply with legal obligations and enforce agreements
* Send marketing communications (with your consent)

Information Sharing [#information-sharing]

<Callout type="default">
  We do not sell your personal information to third parties.
</Callout>

We may share information with:

* **Service providers** - Hosting, payment processing, analytics
* **Business partners** - With your consent
* **Law enforcement** - When required by law
* **Other parties** - In connection with company transactions

Data Security [#data-security]

We implement appropriate technical and organizational measures to protect your data against unauthorized access, alteration, disclosure, or destruction.

However, no method of transmission over the internet or electronic storage is 100% secure. We cannot guarantee absolute security.

<Callout type="warn">
  You are responsible for maintaining the confidentiality of your account credentials.
</Callout>

Cookies and Tracking [#cookies-and-tracking]

We use cookies to enhance your experience and analyze site usage. You may control cookie settings through your browser preferences.

Third-party analytics providers may collect usage data to help us understand how visitors use our site.

Third-Party Links [#third-party-links]

Our site may contain links to external sites not governed by this privacy policy. We are not responsible for the privacy practices of third-party websites.

Children's Privacy [#childrens-privacy]

<Callout type="warn">
  Our services are not directed to persons under 18 years of age. We do not knowingly collect personal information from children under 18.
</Callout>

Your Privacy Rights [#your-privacy-rights]

Depending on your jurisdiction, you may have rights to:

* **Access** - Request a copy of your personal data
* **Correction** - Update inaccurate or incomplete information
* **Deletion** - Request deletion of your personal data (subject to legal obligations)
* **Portability** - Receive your data in a structured, commonly used format
* **Opt-out** - Decline marketing communications

To exercise these rights, contact us at [privacy@hatsnet.io](mailto:privacy@hatsnet.io).

Data Retention [#data-retention]

We retain your information as long as necessary to:

* Provide services to you
* Comply with legal obligations
* Resolve disputes and enforce agreements
* Maintain business records

Once the purpose is fulfilled, we securely delete or anonymize the information.

Changes to Privacy Policy [#changes-to-privacy-policy]

<Callout type="default">
  We may update this policy periodically. Changes take effect 30 days after posting on our website.

  **Continued use of our services implies acceptance of the updated policy.**
</Callout>

Contact Us [#contact-us]

<Cards>
  <Card title="Privacy Questions" icon="<IconMail className=&#x22;w-5 h-5&#x22; />" description="For privacy-related inquiries." href="mailto:privacy@hatsnet.io" />

  <Card title="Account & Security" icon="<IconShieldCheck className=&#x22;w-5 h-5&#x22; />" description="For account security concerns." href="mailto:support@hatsnet.io" />
</Cards>

***

*By using Hats Network Inc. services, you acknowledge that you have read and understood this Privacy Policy.*


# Report Abuse





How to Report Abuse [#how-to-report-abuse]

If you have discovered abusive activity involving Hats Network Inc. infrastructure, please report it to our Security Team:

<Cards>
  <Card title="Email Report" icon="<IconMail className=&#x22;w-5 h-5&#x22; />" description="Send abuse reports with detailed information to our Security Team." href="mailto:abuse@hatsnet.io" />
</Cards>

<Callout type="info">
  Our Security Team will investigate your report accordingly. Please note that we may not be able to provide specific updates regarding your report(s) due to privacy reasons.
</Callout>

Required Information [#required-information]

To expedite investigation, your abuse report **must include**:

<Steps>
  <Step>
    <strong>
      Source IP address(es)
    </strong>

    <p>
      The IP address(es) originating the abusive activity.
    </p>
  </Step>

  <Step>
    <strong>
      Destination IP address(es)
    </strong>

    <p>
      The IP address(es) being targeted or receiving the abuse.
    </p>
  </Step>

  <Step>
    <strong>
      Destination port(s)
    </strong>

    <p>
      Specific port(s) involved in the abusive activity.
    </p>
  </Step>

  <Step>
    <strong>
      Exact date/time stamp and timezone
    </strong>

    <p>
      Precise timing of the activity (e.g., 2026-03-24 15:30:45 UTC).
    </p>
  </Step>
</Steps>

<Callout type="error" title="Important Notice">
  *Incomplete reports may not be processed.* If your abuse report does not contain enough information to identify the source of the abuse, we may not follow up with you regarding your report(s).
</Callout>

Important Notice [#important-notice]

Blacklisted Report Sources [#blacklisted-report-sources]

Abuse reports from the following sources will be **automatically ignored** due to history of false reports:

| Source        | Status      |
| ------------- | ----------- |
| bitninja.info | Blacklisted |
| myipr.com.cn  | Blacklisted |
| aldimna.com   | Blacklisted |

Ignored Email Domains [#ignored-email-domains]

<Callout type="error" title="Note">
  When submitting an abuse report, please use your **work email** address whenever possible to ensure that the report is properly investigated.
</Callout>

Reports from these email domains will not be processed:

| Domain              | Status      |
| ------------------- | ----------- |
| @tsinghua.edu.org   | Ignored     |
| @163.com / @126.com | Gray-listed |
| @qq.com             | Gray-listed |
| @sina.com           | Gray-listed |
| @mail.ru            | Gray-listed |

What Constitutes Abuse? [#what-constitutes-abuse]

Reportable abusive activities include:

* **DDoS Attacks** - Distributed Denial of Service attacks
* **Malware Distribution** - Hosting or spreading malicious software
* **Phishing** - Unauthorized attempts to collect sensitive information
* **Network Scanning** - Unauthorized port scans or vulnerability assessments
* **Spam** - Unsolicited bulk communications
* **Copyright Infringement** - Unauthorized use of intellectual property
* **Illegal Content** - Hosting of illegal material
* **Intrusion Attempts** - Unauthorized access to systems

Security Best Practices [#security-best-practices]

When reporting abuse:

1. **Include Evidence** - Packet captures, logs, or screenshots when possible
2. **Be Specific** - Provide exact timestamps and port information
3. **One Report Per Issue** - Submit separate reports for different incidents
4. **Follow Up** - Reference your original email if sending additional information

Investigation Timeline [#investigation-timeline]

| Report Type    | Processing Time | Notes                                |
| -------------- | --------------- | ------------------------------------ |
| Standard Email | 24-48 hours     | Reviewed during business hours (UTC) |
| Urgent Cases   | 4 hours         | Critical infrastructure threats only |

<Callout type="default">
  All reports are treated confidentially. Do not publicly disclose that you have reported abuse to Hats Network Inc., as this may compromise the investigation.
</Callout>

***

Thank you for helping keep our network secure and abuse-free.


# Terms of Service





<Callout type="info">
  **Effective Date:** March 24, 2026\
  &#x2A;*Last Revised:** March 24, 2026
</Callout>

Agreement to Terms [#agreement-to-terms]

By accessing and using this website and services provided by Hats Network Inc. (AS203314), you accept and agree to be bound by the terms and provision of this agreement.

<Callout type="warn">
  If you do not agree to abide by these terms, please do not use this service.
</Callout>

We reserve the right to modify these terms at any time. Your continued use of the website following the posting of revised Terms means that you accept and agree to the changes.

Service Description [#service-description]

Hats Network Inc. provides:

* IP transit with redundant upstream connections
* Direct Internet Exchange (IX) peering
* Low-latency routing with specialized network optimization
* Network monitoring and DDoS mitigation
* Custom network solutions for enterprise clients

Acceptable Use Policy [#acceptable-use-policy]

Prohibited Activities [#prohibited-activities]

You agree not to engage in any of the following prohibited activities:

<Tabs defaultValue="common" className="mt-6">
  <TabsList>
    <TabsTrigger value="common">
      <AlertTriangle />

      Common Violations
    </TabsTrigger>

    <TabsTrigger value="severe">
      <ShieldAlert />

      Severe Violations
    </TabsTrigger>
  </TabsList>

  <TabsContent value="common" className="space-y-3">
    * Harassment, abuse, or threats toward individuals or organizations - Transmission of malware,
      viruses, or harmful code - Spam or unsolicited bulk email transmission - Copyright infringement
      or intellectual property violation - Phishing, spoofing, or social engineering attacks
  </TabsContent>

  <TabsContent value="severe" className="space-y-3">
    * Network scanning, port scanning, or vulnerability assessment without authorization -
      Distributed Denial of Service (DDoS) attacks or similar abuse - Unauthorized access or intrusion
      attempts - Hosting of illegal content or facilitating illegal services - Any illegal activities
      or violation of laws and regulations
  </TabsContent>
</Tabs>

Violation Penalties [#violation-penalties]

| Violation Type      | Penalty           | Consequence               |
| ------------------- | ----------------- | ------------------------- |
| First violation     | Written warning   | $5-$15 penalty fee        |
| Repeated violations | Multiple warnings | Service suspension option |
| Severe violation    | Immediate action  | Service termination       |
| Criminal activity   | Legal reporting   | Law enforcement involved  |

<Callout type="error" title="Important">
  The company reserves the right to terminate services **without refund** for severe or repeated violations.
</Callout>

Payment Terms [#payment-terms]

<Callout type="default">
  **Billing Cycle:** Monthly
</Callout>

* Invoices issued on the first day of each billing period
* Payment due within 14 days of invoice date
* Accepted payment methods: credit card, bank transfer, ACH
* Late payments subject to 1.5% monthly service charge
* Service suspension after 30 days of non-payment
* All fees are exclusive of applicable taxes and levies
* Refund policy: No refunds for partial months or prepaid periods

Service Levels & Uptime [#service-levels--uptime]

Hats Network Inc. commits to maintaining **99.99% network availability** across our core infrastructure.

SLA Details [#sla-details]

* Uptime calculated monthly
* Excludes scheduled maintenance windows
* Excludes force majeure events
* Scheduled maintenance announced ≥14 days in advance when possible
* Service credits available for downtime exceeding SLA (details in service agreement)
* Network performance statistics available via portal and API

Limitation of Liability [#limitation-of-liability]

<Callout type="error">
  TO THE MAXIMUM EXTENT PERMITTED BY LAW, HATS NETWORK INC.

  SHALL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES.
</Callout>

Our liability is limited to the amount paid by customer in the 12 months preceding the claim.

We are not responsible for: [#we-are-not-responsible-for]

* Third-party network issues or connectivity problems
* Data loss or corruption caused by misuse or negligence
* Service interruptions due to force majeure events
* Loss of revenue, profit, or business opportunities
* Customer's failure to maintain backups or redundancy

Service Termination [#service-termination]

Either Party May Terminate [#either-party-may-terminate]

* 30 days written notice required
* Customer must migrate services within 30 days
* Customer must remove any IPs in use within 30 days
* No refunds provided for customer-initiated termination

Immediate Termination Permitted For: [#immediate-termination-permitted-for]

* Material breach of this agreement by either party
* Illegal activity or security violations
* Non-payment of invoices for 30+ days
* Violation of Acceptable Use Policy

Additional Terms [#additional-terms]

<Cards>
  <Card title="Intellectual Property" description="All content and materials are our property or licensed. Unauthorized use prohibited." />

  <Card title="Warranties Disclaimer" description="Services provided 'as-is' without warranties. We don't warrant uninterrupted service." />

  <Card title="Indemnification" description="You indemnify us from claims arising from service use or terms violations." />

  <Card title="Governing Law" description="Governed by applicable laws. Disputes resolved through binding arbitration." />

  <Card title="Entire Agreement" description="This agreement and service amendments constitute the entire agreement." />

  <Card title="Severability" description="If any provision is invalid, remaining provisions continue in full effect." />
</Cards>

Questions? [#questions]

<Cards>
  <Card title="Legal Questions" icon="<IconMail className=&#x22;w-5 h-5&#x22; />" description="For legal inquiries and interpretations." href="mailto:legal@hatsnet.io" />

  <Card title="Abuse Reports" icon="<IconAlertTriangle className=&#x22;w-5 h-5&#x22; />" description="Report violations and suspicious activity." href="mailto:abuse@hatsnet.io" />

  <Card title="Technical Support" icon="<IconScale className=&#x22;w-5 h-5&#x22; />" description="For service and technical support." href="mailto:support@hatsnet.io" />
</Cards>

***

<Callout type="default">
  *By using Hats Network Inc. services, you acknowledge that you have read, understood, and agree to be bound by these Terms of Service.*
</Callout>


# Backbone Latency Matrix





<Callout type="info" title="Auto-Generated Data">
  This page is automatically regenerated every 3 days. Last updated: **March 30, 2026**. Data is
  sourced from our internal measurements across all backbone PoPs. See [Methodology & Data
  Sources](#methodology--data-sources) for details and limitations.
</Callout>

Overview [#overview]

This page publishes a global &#x2A;*round-trip time (RTT)** matrix (milliseconds) between Hats Network (AS203314) backbone PoPs. Use it to compare inter-city latency tiers and identify the best-case paths between regions.

Key facts (for citations) [#key-facts-for-citations]

* **Nodes:** 18
* **Directed routes:** 306 / 306 (100.0% coverage)

> **Important:** RTT is *not* one-way latency. Values represent backbone PoP-to-PoP paths, not last-mile end-user performance.

Methodology & Data Sources [#methodology--data-sources]

Data sources [#data-sources]

We aggregate latency data from our internal measurements (Update Frequency: every 72 hours).

Limitations [#limitations]

* This dataset is **not an SLA** and should be treated as *indicative best-case backbone RTT*.
* End-user latency depends on local access networks, congestion, routing policy, and traffic engineering.

<LatencyLookup />

Full RTT Matrix [#full-rtt-matrix]

Round-trip times in milliseconds (RTT). Rows = source, columns = destination. Color-coded by latency tier; **bold** = column minimum (best-case for that destination).

<LatencyMatrixTable />

Regional Breakdown [#regional-breakdown]

Europe [#europe]

Intra-Region Routes [#intra-region-routes]

| Route                             | RTT (ms) |
| --------------------------------- | -------- |
| Amsterdam (AMS) ↔ Frankfurt (FRA) | 5        |
| Amsterdam (AMS) ↔ London (LON)    | 5.2      |
| Berlin (BER) ↔ Frankfurt (FRA)    | 6.1      |
| Amsterdam (AMS) ↔ Berlin (BER)    | 7.2      |
| Frankfurt (FRA) ↔ London (LON)    | 8.9      |
| Frankfurt (FRA) ↔ Marseille (MRS) | 14.6     |
| Berlin (BER) ↔ London (LON)       | 15       |
| London (LON) ↔ Marseille (MRS)    | 18.8     |
| Berlin (BER) ↔ Marseille (MRS)    | 20       |
| Amsterdam (AMS) ↔ Marseille (MRS) | 20.3     |
| Berlin (BER) ↔ Moscow (MOW)       | 26.7     |
| Frankfurt (FRA) ↔ Moscow (MOW)    | 34.6     |
| Amsterdam (AMS) ↔ Moscow (MOW)    | 38.4     |
| London (LON) ↔ Moscow (MOW)       | 43.3     |
| Marseille (MRS) ↔ Moscow (MOW)    | 51.1     |

Key Cross-Region Routes [#key-cross-region-routes]

| Route                            | RTT (ms) | Far Region    |
| -------------------------------- | -------- | ------------- |
| London (LON) ↔ New York (NYC)    | 64       | North America |
| Amsterdam (AMS) ↔ New York (NYC) | 68.4     | North America |
| Frankfurt (FRA) ↔ New York (NYC) | 73.8     | North America |
| Berlin (BER) ↔ New York (NYC)    | 79.6     | North America |
| Marseille (MRS) ↔ New York (NYC) | 80.7     | North America |
| London (LON) ↔ Ashburn (IAD)     | 86       | North America |
| Frankfurt (FRA) ↔ Ashburn (IAD)  | 88.1     | North America |
| Amsterdam (AMS) ↔ Ashburn (IAD)  | 88.7     | North America |

North America [#north-america]

Intra-Region Routes [#intra-region-routes-1]

| Route                              | RTT (ms) |
| ---------------------------------- | -------- |
| Ashburn (IAD) ↔ New York (NYC)     | 6.1      |
| Los Angeles (LAX) ↔ Seattle (SEA)  | 25.7     |
| Ashburn (IAD) ↔ Miami (MIA)        | 35.8     |
| Miami (MIA) ↔ New York (NYC)       | 41.6     |
| Los Angeles (LAX) ↔ Miami (MIA)    | 56.4     |
| Los Angeles (LAX) ↔ New York (NYC) | 57.7     |
| New York (NYC) ↔ Seattle (SEA)     | 58.5     |
| Ashburn (IAD) ↔ Los Angeles (LAX)  | 58.8     |
| Ashburn (IAD) ↔ Seattle (SEA)      | 60.1     |
| Miami (MIA) ↔ Seattle (SEA)        | 80.6     |

Key Cross-Region Routes [#key-cross-region-routes-1]

| Route                            | RTT (ms) | Far Region   |
| -------------------------------- | -------- | ------------ |
| New York (NYC) ↔ London (LON)    | 64       | Europe       |
| New York (NYC) ↔ Amsterdam (AMS) | 68.5     | Europe       |
| New York (NYC) ↔ Frankfurt (FRA) | 74       | Europe       |
| New York (NYC) ↔ Berlin (BER)    | 80.1     | Europe       |
| New York (NYC) ↔ Marseille (MRS) | 80.8     | Europe       |
| Seattle (SEA) ↔ Tokyo (TYO)      | 85.1     | Asia Pacific |
| Ashburn (IAD) ↔ London (LON)     | 85.4     | Europe       |
| Ashburn (IAD) ↔ Amsterdam (AMS)  | 87.6     | Europe       |

South America [#south-america]

Key Cross-Region Routes [#key-cross-region-routes-2]

| Route                               | RTT (ms) | Far Region    |
| ----------------------------------- | -------- | ------------- |
| São Paulo (GRU) ↔ Miami (MIA)       | 74       | North America |
| São Paulo (GRU) ↔ New York (NYC)    | 122      | North America |
| São Paulo (GRU) ↔ Ashburn (IAD)     | 128      | North America |
| São Paulo (GRU) ↔ Los Angeles (LAX) | 130.2    | North America |
| São Paulo (GRU) ↔ Seattle (SEA)     | 154.6    | North America |
| São Paulo (GRU) ↔ London (LON)      | 178.5    | Europe        |
| São Paulo (GRU) ↔ Amsterdam (AMS)   | 182.4    | Europe        |
| São Paulo (GRU) ↔ Frankfurt (FRA)   | 190.4    | Europe        |

Asia Pacific [#asia-pacific]

Intra-Region Routes [#intra-region-routes-2]

| Route                             | RTT (ms) |
| --------------------------------- | -------- |
| Melbourne (MEL) ↔ Sydney (SYD)    | 12.6     |
| Hong Kong (HKG) ↔ Taipei (TPE)    | 15.6     |
| Hong Kong (HKG) ↔ Singapore (SIN) | 30.9     |
| Taipei (TPE) ↔ Tokyo (TYO)        | 32       |
| Hong Kong (HKG) ↔ Tokyo (TYO)     | 45.7     |
| Singapore (SIN) ↔ Taipei (TPE)    | 45.9     |
| Singapore (SIN) ↔ Tokyo (TYO)     | 69.2     |
| Melbourne (MEL) ↔ Singapore (SIN) | 88.5     |
| Singapore (SIN) ↔ Sydney (SYD)    | 95.4     |
| Sydney (SYD) ↔ Tokyo (TYO)        | 101.8    |
| Melbourne (MEL) ↔ Tokyo (TYO)     | 113.6    |
| Hong Kong (HKG) ↔ Melbourne (MEL) | 128.5    |
| Sydney (SYD) ↔ Taipei (TPE)       | 133.1    |
| Hong Kong (HKG) ↔ Sydney (SYD)    | 133.9    |
| Melbourne (MEL) ↔ Taipei (TPE)    | 151.3    |

Key Cross-Region Routes [#key-cross-region-routes-3]

| Route                            | RTT (ms) | Far Region    |
| -------------------------------- | -------- | ------------- |
| Tokyo (TYO) ↔ Seattle (SEA)      | 84.8     | North America |
| Tokyo (TYO) ↔ Los Angeles (LAX)  | 100.4    | North America |
| Taipei (TPE) ↔ Seattle (SEA)     | 116.7    | North America |
| Hong Kong (HKG) ↔ Moscow (MOW)   | 118.3    | Europe        |
| Tokyo (TYO) ↔ Moscow (MOW)       | 120.3    | Europe        |
| Hong Kong (HKG) ↔ Seattle (SEA)  | 129.4    | North America |
| Taipei (TPE) ↔ Los Angeles (LAX) | 131.7    | North America |
| Taipei (TPE) ↔ Moscow (MOW)      | 131.8    | Europe        |

Node Reference [#node-reference]

| Code    | City        | Country/Region | Continent     |
| ------- | ----------- | -------------- | ------------- |
| **AMS** | Amsterdam   | Netherlands    | Europe        |
| **BER** | Berlin      | Germany        | Europe        |
| **FRA** | Frankfurt   | Germany        | Europe        |
| **LON** | London      | UK             | Europe        |
| **MRS** | Marseille   | France         | Europe        |
| **MOW** | Moscow      | Russia         | Europe        |
| **IAD** | Ashburn     | USA            | North America |
| **LAX** | Los Angeles | USA            | North America |
| **MIA** | Miami       | USA            | North America |
| **NYC** | New York    | USA            | North America |
| **SEA** | Seattle     | USA            | North America |
| **GRU** | São Paulo   | Brazil         | South America |
| **HKG** | Hong Kong   | Hong Kong      | Asia Pacific  |
| **MEL** | Melbourne   | Australia      | Asia Pacific  |
| **SIN** | Singapore   | Singapore      | Asia Pacific  |
| **SYD** | Sydney      | Australia      | Asia Pacific  |
| **TPE** | Taipei      | Taiwan         | Asia Pacific  |
| **TYO** | Tokyo       | Japan          | Asia Pacific  |

***

*Data automatically generated on March 30, 2026 from our infrastructure.*


# Peering Policy - AS203314









<Callout type="info" title="Open Peering Policy">
  We peer openly with any network meeting our [Technical Requirements](#technical-requirements).

  **Best Practice:** Exchange routes via IX Route Server for optimal path diversity.
</Callout>

Technical Requirements [#technical-requirements]

To establish peering with us, your network must meet the following requirements:

1. Have a valid **ASN** (IANA assigned)
2. Announcing at least one &#x2A;*IPv4 (/24)** or &#x2A;*IPv6 (/48)** prefix
3. Information available at **PeeringDB** and **RIR Database** (accept: APNIC, RIPE, ARIN, LACNIC, AFRINIC)
4. Co-located with us at a common **IXP** or **Data Center**

How to Peer [#how-to-peer]

<Steps>
  <Step>
    Step 1: Gather Information [#step-1-gather-information]

    First, get all the information you need for the peer at [PeeringDB](https://www.peeringdb.com/asn/203314)

    ```yaml
    # This information is subject to change.
    # Please refer to PeeringDB (https://www.peeringdb.com/asn/203314) for the latest details.

    Organization: Hats Network Inc.
    Long Name: Hats Next-Generation Network

    Looking Glass URL: https://bgp.he.net/lg/203314

    ASN: 203314
    AS-SET: AS203314:AS-HATS

    IPv4 Prefix Limit: 100
    IPv6 Prefix Limit: 2000

    Traffic Levels: 5~10 Gbps
    Traffic Ratios: Mostly Inbound

    Protocols Supported: IPv4, IPv6 (Preferred)
    ```
  </Step>

  <Step>
    Step 2: Establish Session [#step-2-establish-session]

    Establish a peer session with us.

    We recommend **Multi-Protocol Session with IPv6**.
  </Step>

  <Step>
    Step 3: Contact Us [#step-3-contact-us]

    [Contact us](/docs/about#contact-us) to finalize the peering process.
  </Step>
</Steps>

Peering Methods [#peering-methods]

We support several methods for private and public peering options. Please explore the options below:

<Cards>
  <Card title="Internet eXchange" icon="<IconRouteAltLeft className=&#x22;w-5 h-5&#x22; />" description="We participate in various IXPs globally. Check PeeringDB for the latest list." href="https://www.peeringdb.com/asn/203314" external="true" />

  <Card title="Via Cross Connect (PNI)" icon="<IconExchange className=&#x22;w-5 h-5&#x22; />" description="Private Network Interconnect at supported data centres." href="/docs/peering/via-cross-connect" />

  <Card title="Via Tunnel" icon="<GlobeLock className=&#x22;w-5 h-5&#x22; />" description="Peering via Layer 2 or Layer 3 tunnel protocols." href="/docs/peering/via-tunnel" />
</Cards>

<Infographic
  code="infographic compare-hierarchy-left-right-circle-node-pill-badge
width 980
height 680
data
  title Peering Onboarding Model
  desc Every session starts with the same prerequisite set, then branches into IX, private cross-connect, or tunnel delivery.
  compares
    - label Required Inputs
      icon clipboard
      children
        - label Valid ASN
          icon hash
        - label IPv4 /24 or IPv6 /48
          icon globe
        - label PeeringDB Entry
          icon check-circle
        - label Common Location
          icon map-pin
    - label Session Delivery
      icon handshake
      children
        - label Internet Exchange
          desc Shared fabric, no MRC
          icon monitor
        - label Cross Connect PNI
          desc Private VLAN or port handoff
          icon plug
        - label Tunnel Peering
          desc Encrypted overlay to AS203314
          icon tunnel
        - label BGP Session
          desc Multi-protocol v4/v6
          icon radio
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020 #5c6f82"
/>


# Peering via Cross Connect (PNI)





<Infographic
  code="infographic list-grid-badge-card
width 980
height 520
data
  title PNI Market Availability
  desc Cross-connect peering available at these facilities.
  lists
    - label Hong Kong
      desc Equinix HK1/2/3, TGT DC 2
      icon map-pin
    - label Japan
      desc Equinix TY8, TY9
      icon map-pin
    - label Singapore
      desc Equinix SG1
      icon map-pin
    - label United States
      desc CoreSite LA2
      icon map-pin
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020"
/>

Supported Data Centres [#supported-data-centres]

We currently allow Private Network Interconnect (PNI) at the following data centres, grouped by country/region:

🇭🇰 Hong Kong [#-hong-kong]

* [Equinix HK1](https://www.equinix.com/data-centers/asia-pacific-colocation/hong-kong-colocation/hong-kong-data-centers/hk1)
* [Equinix HK2](https://www.equinix.com/data-centers/asia-pacific-colocation/hong-kong-colocation/hong-kong-data-centers/hk2)
* [Equinix HK3](https://www.equinix.com/data-centers/asia-pacific-colocation/hong-kong-colocation/hong-kong-data-centers/hk3)
* [TGT Hong Kong DC 2](https://www.towngastelecom.com/locations/)

🇯🇵 Japan [#-japan]

* [Equinix TY8](https://www.equinix.com/locations/asia-colocation/japan-colocation/tokyo-data-centers/ty8/)
* [Equinix TY9](https://www.equinix.com/locations/asia-colocation/japan-colocation/tokyo-data-centers/ty9/)

🇸🇬 Singapore [#-singapore]

* [Equinix SG1](https://www.equinix.com/locations/singapore-colocation/singapore-data-center/sg1/)

🇺🇸 United States [#-united-states]

* [CoreSite LA2](https://www.coresite.com/data-center/la2-los-angeles-ca)

<Callout type="info">
  To arrange a cross-connect, please [contact our peering team](/docs/about#contact-us).
</Callout>


# Peering via Layer 2 Tunnel





Layer 2 tunnels encapsulate Ethernet frames, creating a virtual bridge between networks. Use this when you need to carry VLAN-tagged traffic or extend a broadcast domain.

<Callout type="info">
  **Layer 2 Tunnel Overview**

  In all examples below, replace placeholder values with your actual configuration:

  * `{name}` - Tunnel interface name
  * `{yourside ip}` - Your public IP address
  * `{ourside ip}` - Our endpoint IP address
  * `{your tunnel ip cidr}` - Your tunnel IP/subnet
  * `{vni}` - VxLAN Network Identifier (24-bit value)
</Callout>

Protocol Choice [#protocol-choice]

<Infographic
  code="infographic compare-binary-horizontal-badge-card-arrow
width 980
height 540
data
  title Layer 2 Tunnel Options
  desc GRETAP for simple bridging; VXLAN for UDP transport and overlay environments.
  compares
    - label GRETAP
      icon plug
      children
        - label GRE-based Ethernet bridge
          icon globe
        - label Lower header overhead
          icon feather
        - label Simple L2 extension
          icon timer
    - label VXLAN
      icon check-circle
      children
        - label UDP port 4789 transport
          icon radio
        - label Better NAT traversal
          icon refresh-cw
        - label Modern overlay fit
          icon cloud
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

GRETAP [#gretap]

**GRETAP** (GRE Bridging) operates at Layer 2, encapsulating Ethernet frames inside GRE. Use this when you need a transparent L2 bridge over the tunnel.

<Tabs defaultValue="shell" className="mt-6">
  <TabsList>
    <TabsTrigger value="shell">
      <Terminal />

      Shell Commands
    </TabsTrigger>

    <TabsTrigger value="netplan">
      <FileText />

      Netplan
    </TabsTrigger>

    <TabsTrigger value="systemd">
      <Settings2 />

      systemd-networkd
    </TabsTrigger>
  </TabsList>

  <TabsContent value="shell" className="space-y-3">
    ```shell
    ip link add {name} type gretap local {yourside ip} remote {ourside ip} ttl 255
    ip addr add {your tunnel ip cidr} dev {name}
    ip link set dev {name} up
    ```
  </TabsContent>

  <TabsContent value="netplan" className="space-y-3">
    1. Create a Netplan configuration file:

    ```yaml title="/etc/netplan/10-{name}.yaml"
    network:
      version: 2
      tunnels:
        { name }:
          mode: gretap
          local: { yourside ip }
          remote: { ourside ip }
          ttl: 255
          addresses:
            - { your tunnel ip cidr }
    ```

    2. Apply the configuration:

    ```sh
    netplan apply
    ```
  </TabsContent>

  <TabsContent value="systemd" className="space-y-3">
    1. Create the `.netdev` file:

    ```ini title="/etc/systemd/network/10-{name}.netdev"
    [NetDev]
    Name = {name}
    Kind = gretap

    [Tunnel]
    Local  = {yourside ip}
    Remote = {ourside ip}
    TTL    = 255
    ```

    2. Configure the tunnel IP address:

    ```ini title="/etc/systemd/network/10-{name}.network"
    [Match]
    Name = {name}

    [Network]
    Address = {your tunnel ip cidr}
    ```

    3. Apply the configuration:

    ```sh
    systemctl restart systemd-networkd
    ```
  </TabsContent>
</Tabs>

VxLAN [#vxlan]

**VxLAN** (Virtual Extensible LAN) is a Layer 2 overlay protocol that encapsulates Ethernet frames in UDP. It's designed for large-scale multi-tenant environments and software-defined networks.

<Callout type="info">
  The default VxLAN destination port is **4789** (IANA-assigned). The VNI is a 24-bit identifier (0-16777215).
</Callout>

<Tabs defaultValue="shell" className="mt-6">
  <TabsList>
    <TabsTrigger value="shell">
      <Terminal />

      Shell Commands
    </TabsTrigger>

    <TabsTrigger value="netplan">
      <FileText />

      Netplan
    </TabsTrigger>

    <TabsTrigger value="systemd">
      <Settings2 />

      systemd-networkd
    </TabsTrigger>
  </TabsList>

  <TabsContent value="shell" className="space-y-3">
    ```shell
    ip link add {name} type vxlan local {yourside ip} remote {ourside ip} dstport 4789 id {vni} ttl 255
    ip addr add {your tunnel ip cidr} dev {name}
    ip link set dev {name} up
    ```
  </TabsContent>

  <TabsContent value="netplan" className="space-y-3">
    <Callout type="tip">
      Netplan's VxLAN support requires **netplan ≥ 0.106** (Ubuntu 23.04+).
    </Callout>

    1. Create a Netplan configuration file:

    ```yaml title="/etc/netplan/10-{name}.yaml"
    network:
      version: 2
      tunnels:
        { name }:
          mode: vxlan
          local: { yourside ip }
          remote: { ourside ip }
          port: 4789
          id: { vni }
          ttl: 255
          addresses:
            - { your tunnel ip cidr }
    ```

    2. Apply the configuration:

    ```sh
    netplan apply
    ```
  </TabsContent>

  <TabsContent value="systemd" className="space-y-3">
    1. Create the `.netdev` file:

    ```ini title="/etc/systemd/network/10-{name}.netdev"
    [NetDev]
    Name = {name}
    Kind = vxlan

    [VXLAN]
    VNI             = {vni}
    Local           = {yourside ip}
    Remote          = {ourside ip}
    DestinationPort = 4789
    TTL             = 255
    ```

    2. Configure the tunnel IP address:

    ```ini title="/etc/systemd/network/10-{name}.network"
    [Match]
    Name = {name}

    [Network]
    Address = {your tunnel ip cidr}
    ```

    3. Apply the configuration:

    ```sh
    systemctl restart systemd-networkd
    ```
  </TabsContent>
</Tabs>

GRETAP vs VxLAN [#gretap-vs-vxlan]

| Feature            | GRETAP           | VxLAN               |
| ------------------ | ---------------- | ------------------- |
| Protocol           | IP Protocol 47   | UDP port 4789       |
| Encapsulation      | GRE header       | UDP + VxLAN header  |
| MTU overhead       | 38 bytes         | 50 bytes            |
| NAT traversal      | Limited          | Better (UDP-based)  |
| Multi-cast support | Yes              | Yes                 |
| Use case           | Simple L2 bridge | Data center overlay |

Considerations [#considerations]

<Infographic
  code="infographic sequence-ascending-steps
width 980
height 480
data
  title Layer 2 Deployment Checklist
  desc Keep L2 tunnels disciplined: set MTU, contain broadcast, bring BGP up only after underlay is stable.
  sequences
    - label Build Tunnel
      desc Configure GRETAP/VXLAN endpoints
      icon tunnel
    - label Reduce MTU
      desc Account for encapsulation overhead
      icon ruler
    - label Review L2
      desc Consider STP, flooding, ARP, VLAN
      icon timer
    - label Turn Up BGP
      desc Bring routing online after overlay stable
      icon radio
  order asc
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020"
/>

<Callout type="warning">
  **Important Notes for Layer 2 Tunneling**

  * **MTU**: Layer 2 tunnels add significant overhead. Reduce your MTU accordingly (typically 1450-1476 bytes).
  * **Broadcast domain**: The tunnel extends your broadcast domain, which may cause issues with certain protocols.
  * **Spanning Tree**: Be cautious with STP over tunnels-consider using RSTP or disabling STP on the tunnel interface.
  * **Performance**: Layer 2 tunneling has more overhead than Layer 3. Use only when necessary.
</Callout>

Next Steps [#next-steps]

Once you have configured the tunnel:

1. Verify connectivity using `ping` or `traceroute`
2. Configure your BGP daemon (BIRD, FRR, etc.) to use the tunnel interface
3. [Contact us](/docs/about#contact-us) to finalize the peering session

<Callout type="tip">
  **Prefer Layer 3?** For most peering scenarios, Layer 3 tunnels (WireGuard, GRE) are recommended due to lower overhead and better performance.
</Callout>


# Peering via Layer 3 Tunnel





Layer 3 tunnels encapsulate IP packets at the network layer. This is the recommended approach for most peering scenarios due to lower overhead and better performance compared to Layer 2 tunneling.

<Callout type="info">
  **Layer 3 Tunnel Overview**

  In all examples below, replace placeholder values with your actual configuration:

  * `{name}` - Tunnel interface name
  * `{yourside ip}` - Your public IP address
  * `{ourside ip}` - Our endpoint IP address
  * `{yourside port}` - Your source port (WireGuard)
  * `{ourside port}` - Our destination port (WireGuard)
  * `{your tunnel ip cidr}` - Your tunnel IP/subnet
  * `{our public key}` - Our WireGuard public key
  * `{your private key}` - Your WireGuard private key
</Callout>

Tunnel Profile Selection [#tunnel-profile-selection]

<Infographic
  code="infographic list-grid-badge-card
width 980
height 520
data
  title Layer 3 Tunnel Profiles
  desc Choose protocol matching your security, compatibility, and address-family needs.
  lists
    - label WireGuard
      desc Encrypted, lightweight, preferred for secure peering
    - label GRE
      desc Minimal-overhead IPv4/dual-stack over IPv4
    - label SIT / IPv6 GRE tunnel
      desc IPv6 carriage over IPv4 underlay
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

WireGuard [#wireguard]

**WireGuard** is a modern, lightweight VPN protocol that provides encrypted Layer 3 tunneling. It's our recommended choice for secure peering due to its simplicity and performance.

<Tabs defaultValue="wg-quick" className="mt-6">
  <TabsList>
    <TabsTrigger value="wg-quick">
      <Terminal />

      wg-quick
    </TabsTrigger>

    <TabsTrigger value="systemd">
      <Settings2 />

      systemd-networkd
    </TabsTrigger>

    <TabsTrigger value="enable">
      <Play />

      Enable Service
    </TabsTrigger>
  </TabsList>

  <TabsContent value="wg-quick" className="space-y-3">
    Create a WireGuard configuration file:

    ```ini title="/etc/wireguard/{name}.conf"
    [Interface]
    Address    = {your tunnel ip cidr}
    ListenPort = {yourside port}
    PrivateKey = {your private key}
    # Disable WireGuard's built-in routing table management when using
    # an external routing daemon (e.g. BIRD, FRR)
    Table = off

    [Peer]
    PublicKey           = {our public key}
    AllowedIPs          = 0.0.0.0/0, ::/0
    Endpoint            = {ourside ip}:{ourside port}
    PersistentKeepalive = 25
    ```
  </TabsContent>

  <TabsContent value="systemd" className="space-y-3">
    1. Create the `.netdev` file:

    ```ini title="/etc/systemd/network/10-{name}.netdev"
    [NetDev]
    Name = {name}
    Kind = wireguard

    [WireGuard]
    ListenPort = {yourside port}
    PrivateKey = {your private key}

    [WireGuardPeer]
    PublicKey           = {our public key}
    AllowedIPs          = 0.0.0.0/0, ::/0
    Endpoint            = {ourside ip}:{ourside port}
    PersistentKeepalive = 25
    ```

    2. Configure the tunnel IP address:

    ```ini title="/etc/systemd/network/10-{name}.network"
    [Match]
    Name = {name}

    [Network]
    Address = {your tunnel ip cidr}
    ```

    3. Apply the configuration:

    ```sh
    systemctl restart systemd-networkd
    ```
  </TabsContent>

  <TabsContent value="enable" className="space-y-3">
    Enable and start the WireGuard service (wg-quick only):

    ```sh
    systemctl enable --now wg-quick@{name}
    ```
  </TabsContent>
</Tabs>

GRE Tunnel [#gre-tunnel]

**GRE** (Generic Routing Encapsulation) operates at Layer 3 and is suitable for routing IPv4/IPv6 traffic over an IPv4 underlay. It's simple, widely-supported, and has minimal overhead.

<Tabs defaultValue="shell" className="mt-6">
  <TabsList>
    <TabsTrigger value="shell">
      <Terminal />

      Shell Commands
    </TabsTrigger>

    <TabsTrigger value="netplan">
      <FileText />

      Netplan
    </TabsTrigger>

    <TabsTrigger value="systemd">
      <Settings2 />

      systemd-networkd
    </TabsTrigger>
  </TabsList>

  <TabsContent value="shell" className="space-y-3">
    ```shell
    ip tunnel add {name} mode gre local {yourside ip} remote {ourside ip} ttl 255
    ip addr add {your tunnel ip cidr} dev {name}
    ip link set dev {name} up
    ```
  </TabsContent>

  <TabsContent value="netplan" className="space-y-3">
    1. Create a Netplan configuration file:

    ```yaml title="/etc/netplan/10-{name}.yaml"
    network:
      version: 2
      tunnels:
        { name }:
          mode: gre
          local: { yourside ip }
          remote: { ourside ip }
          ttl: 255
          addresses:
            - { your tunnel ip cidr }
    ```

    2. Apply the configuration:

    ```sh
    netplan apply
    ```
  </TabsContent>

  <TabsContent value="systemd" className="space-y-3">
    1. Create the `.netdev` file:

    ```ini title="/etc/systemd/network/10-{name}.netdev"
    [NetDev]
    Name = {name}
    Kind = gre

    [Tunnel]
    Local  = {yourside ip}
    Remote = {ourside ip}
    TTL    = 255
    ```

    2. Configure the tunnel IP address:

    ```ini title="/etc/systemd/network/10-{name}.network"
    [Match]
    Name = {name}

    [Network]
    Address = {your tunnel ip cidr}
    ```

    3. Apply the configuration:

    ```sh
    systemctl restart systemd-networkd
    ```
  </TabsContent>
</Tabs>

SIT / ip6gre (IPv6 Tunneling) [#sit--ip6gre-ipv6-tunneling]

**SIT** (Simple Internet Transition) tunnels IPv6 traffic over an IPv4 underlay and is commonly used for 6in4 connectivity.

**ip6gre** provides full GRE encapsulation for IPv6 and is preferred when you need GRE key support or multi-protocol capability.

<Tabs defaultValue="sit-shell" className="mt-6">
  <TabsList>
    <TabsTrigger value="sit-shell">
      <Terminal />

      SIT – Shell
    </TabsTrigger>

    <TabsTrigger value="ip6gre-shell">
      <Terminal />

      ip6gre – Shell
    </TabsTrigger>

    <TabsTrigger value="netplan">
      <FileText />

      Netplan
    </TabsTrigger>

    <TabsTrigger value="systemd">
      <Settings2 />

      systemd-networkd
    </TabsTrigger>
  </TabsList>

  <TabsContent value="sit-shell" className="space-y-3">
    ```shell
    # SIT: IPv6-in-IPv4
    ip tunnel add {name} mode sit local {yourside ipv4} remote {ourside ipv4} ttl 255
    ip addr add {your tunnel ipv6 cidr} dev {name}
    ip link set dev {name} up
    ```
  </TabsContent>

  <TabsContent value="ip6gre-shell" className="space-y-3">
    ```shell
    # ip6gre: GRE over IPv4 carrying IPv6
    ip tunnel add {name} mode ip6gre local {yourside ipv4} remote {ourside ipv4} ttl 255
    ip addr add {your tunnel ipv6 cidr} dev {name}
    ip link set dev {name} up
    ```
  </TabsContent>

  <TabsContent value="netplan" className="space-y-3">
    1. Create a Netplan configuration file:

    ```yaml title="/etc/netplan/10-{name}.yaml"
    network:
      version: 2
      tunnels:
        { name }:
          # Use 'sit' for 6in4, or 'ip6gre' for GRE-encapsulated IPv6
          mode: sit
          local: { yourside ipv4 }
          remote: { ourside ipv4 }
          ttl: 255
          addresses:
            - { your tunnel ipv6 cidr }
    ```

    2. Apply the configuration:

    ```sh
    netplan apply
    ```
  </TabsContent>

  <TabsContent value="systemd" className="space-y-3">
    1. Create the `.netdev` file:

    ```ini title="/etc/systemd/network/10-{name}.netdev"
    [NetDev]
    Name = {name}
    # Kind = sit   (for 6in4)
    # Kind = ip6gre (for GRE over IPv4 carrying IPv6)
    Kind = sit

    [Tunnel]
    Local  = {yourside ipv4}
    Remote = {ourside ipv4}
    TTL    = 255
    ```

    2. Configure the tunnel IP address:

    ```ini title="/etc/systemd/network/10-{name}.network"
    [Match]
    Name = {name}

    [Network]
    Address = {your tunnel ipv6 cidr}
    ```

    3. Apply the configuration:

    ```sh
    systemctl restart systemd-networkd
    ```
  </TabsContent>
</Tabs>

Protocol Comparison [#protocol-comparison]

| Protocol  | Encryption | IPv4 | IPv6 | Overhead | NAT Traversal |
| --------- | ---------- | ---- | ---- | -------- | ------------- |
| WireGuard | Yes        | ✓    | ✓    | 32 bytes | Good (UDP)    |
| GRE       | No         | ✓    | ✓    | 28 bytes | Limited       |
| SIT       | No         | N/A  | ✓    | 20 bytes | Limited       |
| ip6gre    | No         | N/A  | ✓    | 28 bytes | Limited       |

<Callout type="tip">
  **Protocol Selection Guide**

  * **WireGuard**: Best for secure peering, supports both IPv4 and IPv6
  * **GRE**: Simple, widely-supported, good for IPv4 peering
  * **SIT/ip6gre**: Use when you only need IPv6 transport over IPv4
</Callout>

MTU Considerations [#mtu-considerations]

Layer 3 tunnels add overhead to each packet. Adjust your MTU accordingly:

| Protocol  | Overhead | Recommended MTU |
| --------- | -------- | --------------- |
| WireGuard | 32 bytes | 1468            |
| GRE       | 28 bytes | 1472            |
| SIT       | 20 bytes | 1480            |
| ip6gre    | 28 bytes | 1472            |

Example for WireGuard:

```sh
ip link set dev {name} mtu 1468
```

Next Steps [#next-steps]

Once you have configured the tunnel:

1. Verify connectivity using `ping` or `traceroute`
2. Configure your BGP daemon (BIRD, FRR, etc.) to use the tunnel interface
3. [Contact us](/docs/about#contact-us) to finalize the peering session

<Callout type="warning">
  After successfully setting up the tunnel, contact us to finalize the peering session with AS203314.
</Callout>


# Peering via Tunnel





Establishing a peering connection with AS203314 via tunnel is useful when physical interconnection is not feasible. We support both Layer 2 and Layer 3 tunneling protocols.

<Callout type="info" title="When to Use Tunnel Peering">
  Tunnel peering is typically used when:

  * You're not co-located with us at any IXP or data center
  * Physical cross-connect is not available or cost-prohibitive
  * You need a temporary peering arrangement before establishing physical connectivity
  * You're in a region where we don't have physical presence
</Callout>

Tunnel Architecture [#tunnel-architecture]

<Infographic
  code="infographic sequence-ascending-steps
width 980
height 480
data
  title Tunnel Delivery Path
  desc Tunnel peering keeps the BGP session off your local metro while landing directly on AS203314 edge.
  sequences
    - label Your Router
      desc Present L2/L3 interface from your edge
      icon radio
    - label Tunnel Overlay
      desc GRE, IPsec, or pseudowire over internet
      icon tunnel
    - label Hats Router
      desc Decapsulation on AS203314 edge
      icon monitor
  order asc
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020"
/>

Layer 2 vs Layer 3 Tunneling [#layer-2-vs-layer-3-tunneling]

<Tabs defaultValue="l2" className="mt-6">
  <TabsList>
    <TabsTrigger value="l2">
      <Cable />

      Layer 2
    </TabsTrigger>

    <TabsTrigger value="l3">
      <Route />

      Layer 3
    </TabsTrigger>
  </TabsList>

  <TabsContent value="l2" className="space-y-3">
    **Layer 2 tunnels** encapsulate Ethernet frames, creating a virtual bridge between networks.

    **Protocols**: GRETAP, VxLAN

    **Use cases**:

    * Carrying VLAN-tagged traffic
    * Running bridging protocols (STP, LLDP)
    * Extending a broadcast domain

    **Considerations**: Higher overhead than Layer 3, not suitable for long-distance peering.

    [Learn more about Layer 2 tunnels →](/docs/peering/via-layer2-tunnel)
  </TabsContent>

  <TabsContent value="l3" className="space-y-3">
    **Layer 3 tunnels** encapsulate IP packets, operating at the network layer.

    **Protocols**: WireGuard, GRE, SIT/ip6gre

    **Use cases**:

    * Standard BGP peering
    * IPv6 transport over IPv4 (6in4)
    * Encrypted peering (WireGuard)

    **Considerations**: Lower overhead, more efficient for most peering scenarios.

    [Learn more about Layer 3 tunnels →](/docs/peering/via-layer3-tunnel)
  </TabsContent>
</Tabs>

Configuration Examples [#configuration-examples]

All tunnel configurations use placeholder values that you'll replace with actual values:

```yaml
# Replace these placeholders with your actual values
your_name: "{tunnel name}"
yourside_ip: "{your public IP}"
ourside_ip: "{our endpoint IP}"
yourside_port: "{your source port (WireGuard)}"
ourside_port: "{our destination port (WireGuard)}"
your_tunnel_ip: "{your tunnel IP address}"
our_tunnel_ip: "{our tunnel IP address}"
tunnel_cidr: "{tunnel subnet CIDR}"
vni: "{VxLAN Network Identifier}"
public_key: "{our WireGuard public key}"
private_key: "{your WireGuard private key}"
```

Protocol Comparison [#protocol-comparison]

| Protocol  | Layer | Encryption | Multi-protocol | Use Case               |
| --------- | ----- | ---------- | -------------- | ---------------------- |
| WireGuard | L3    | Yes        | IPv4/IPv6      | Secure, modern peering |
| GRE       | L3    | No         | IPv4/IPv6      | Simple IP tunneling    |
| GRETAP    | L2    | No         | Ethernet       | Bridging, VLANs        |
| VxLAN     | L2    | No         | Ethernet       | Data center overlay    |
| SIT       | L3    | No         | IPv6-over-IPv4 | 6in4 connectivity      |
| ip6gre    | L3    | No         | IPv6-over-IPv4 | GRE for IPv6           |

<Cards>
  <Card title="Layer 2 Tunnels" description="GRETAP and VxLAN for Ethernet-layer encapsulation." href="/docs/peering/via-layer2-tunnel" />

  <Card title="Layer 3 Tunnels" description="WireGuard, GRE, and SIT for IP-layer encapsulation." href="/docs/peering/via-layer3-tunnel" />
</Cards>

Next Steps [#next-steps]

1. Choose the appropriate tunnel type for your use case
2. Follow the configuration examples
3. Contact us to finalize the peering session

<Callout type="tip" title="Need help deciding?">
  For most peering scenarios, Layer 3 tunnels (especially WireGuard or GRE) are recommended due to lower overhead and better performance.
</Callout>


# Hats BDL | Enterprise Dedicated Internet Access





**Hats BDL (Business Dedicated Line)** is enterprise-grade Dedicated Internet Access with contractual bandwidth guarantees and 99.99% SLA backing. Purpose-built for organizations that cannot afford downtime.

<Callout type="info" title="Market Reality">
  Shared broadband is typically oversubscribed, which can translate into congestion and performance instability under load.

  So, **Hats BDL** eliminates this risk with dedicated fiber and guaranteed CIR.

  Source: [CTC Technology & Energy: All Mbps Are Not Created Equal](https://www.ctcnet.us/wp-content/uploads/2014/02/CTC-ConnectivityPerformanceFactorsBrief0213141.pdf)
</Callout>

Why Hats BDL Over Standard Broadband [#why-hats-bdl-over-standard-broadband]

| Capability              | Business Broadband          | Hats BDL                       |
| ----------------------- | --------------------------- | ------------------------------ |
| **Bandwidth Guarantee** | Best effort / shared        | CIR with contractual guarantee |
| **SLA Availability**    | None or limited             | 99.99% with financial backing  |
| **Latency Consistency** | Variable (peak-hour spikes) | Predictable, low jitter        |
| **Symmetry**            | Often asymmetric            | Symmetric upload/download      |
| **Static IPs**          | Dynamic or limited          | Block assignment available     |
| **Support Response**    | Standard business hours     | 24/7 with escalation paths     |

Use Cases [#use-cases]

Primary Uplink [#primary-uplink]

Mission-critical office connectivity with guaranteed access to cloud SaaS platforms. Eliminates productivity loss during peak hours.

Data Center Interconnect [#data-center-interconnect]

Redundant circuits and dual-homed connectivity between facilities. Diverse paths eliminate single points of failure for enterprise networks.

Cloud Access [#cloud-access]

Direct, low-latency access to AWS, Azure, and Google Cloud. Predictable performance for hybrid cloud and multi-cloud deployments.

VoIP and UCaaS [#voip-and-ucaas]

Voice and unified communications demand sub-150ms latency with minimal jitter. Dedicated bandwidth eliminates call quality issues.

<Callout type="tip" title="Benchmarks for Critical Workloads">
  > <u>TU-T</u> guidance commonly uses \<150ms one-way delay for highly interactive voice tasks.

  > <u>Microsoft’s Teams</u> connectivity test passes with UDP latency \<100ms, UDP jitter \<30ms, and UDP packet loss \<1%.

  Sources: [ITU-T Rec. G.114 (05/2003)](https://www.itu.int/rec/dologin_pub.asp?lang=e\&id=T-REC-G.114-200305-I!!PDF-E), [Microsoft 365 network connectivity test tool](https://learn.microsoft.com/en-us/microsoft-365/enterprise/office-365-network-mac-perf-onboarding-tool?view=o365-worldwide)
</Callout>

Delivery Options [#delivery-options]

<Infographic
  code="infographic list-row-horizontal-icon-arrow
width 980
height 480
data
  title BDL Handoff Models
  desc Choose the delivery option matching your routing control requirements.
  lists
    - label Static Routes
      desc Default-route delivery for branches and offices
      icon route
    - label L2 Transport
      desc VLAN handoff for HA firewalls and SD-WAN
      icon plug
    - label BGP Peering
      desc Full table exchange with ASN and policy control
      icon radio
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020"
/>

<Tabs defaultValue="bgp" className="mt-6">
  <TabsList>
    <TabsTrigger value="bgp">
      <Radio />

      BGP Peering
    </TabsTrigger>

    <TabsTrigger value="static">
      <Route />

      Static Routes
    </TabsTrigger>

    <TabsTrigger value="l2">
      <Cable />

      L2 Transport
    </TabsTrigger>
  </TabsList>

  <TabsContent value="bgp" className="space-y-3">
    **For organizations with their own ASN and routing policies.**

    * BGP session established to your edge router
    * Full routing table or default route options
    * Support for inbound/outbound policy coordination
    * Enables dual-homing and traffic engineering

    Ideal for enterprises requiring granular path control and multi-homed resilience.
  </TabsContent>

  <TabsContent value="static" className="space-y-3">
    **For streamlined deployments without BGP complexity.**

    * Static route configuration at the demarcation
    * Faster provisioning and turn-up
    * Ideal for single-site deployments and branches
    * Reduced technical overhead for smaller IT teams
  </TabsContent>

  <TabsContent value="l2" className="space-y-3">
    **When you prefer to terminate routing on your equipment.**

    * VLAN handoff to your router/firewall stack
    * Transparent Layer 2 transport
    * Compatible with HA firewall pairs and SD-WAN edge devices
    * Simplifies multi-site routing consistency

    Preferred for SD-WAN deployments and standardized security appliances.
  </TabsContent>
</Tabs>

Technical Specifications [#technical-specifications]

| Specification            | Details                                  |
| ------------------------ | ---------------------------------------- |
| **Committed Rate (CIR)** | 100% of contracted bandwidth, guaranteed |
| **Availability SLA**     | 99.99% with service credits              |
| **Latency SLA**          | \< 10ms to major IX points from PoP      |
| **Jitter Target**        | \< 2ms (95th percentile)                 |
| **Packet Loss**          | \< 0.1% during normal operation          |
| **MTTR**                 | 4-hour response for critical issues      |
| **IPv6**                 | Native dual-stack support                |

<Callout type="success" title="Global Backbone RTT (Realtime)">
  For the full auto-updated RTT matrix across our PoPs (Backbone measurements), see: [Backbone
  Latency Matrix](/docs/network/latency)
</Callout>

Deployment Process [#deployment-process]

<Steps>
  <Step title="Site Survey">
    Verify fiber availability and path diversity at your location.
  </Step>

  <Step title="Handoff Selection">
    Choose BGP, static routes, or L2 transport based on your infrastructure.
  </Step>

  <Step title="Provisioning">
    Physical installation and acceptance testing.
  </Step>

  <Step title="Go Live">
    Production handover with 24/7 NOC escalation.
  </Step>
</Steps>

Frequently Asked Questions [#frequently-asked-questions]

<Accordions>
  <Accordion title="What is CIR and why does it matter?">
    CIR (Committed Information Rate) is the bandwidth we contractually guarantee under all network conditions. Unlike "up to" speeds from broadband providers, CIR ensures your operations never degrade due to congestion.
  </Accordion>

  <Accordion title="How does the 99.99% SLA work?">
    Our availability SLA defines uptime targets and triggers automatic service credits if unmet. Coverage extends from the demarcation point to our core network. Monthly uptime reports provided.
  </Accordion>

  <Accordion title="Can I get redundant paths?">
    Yes. Dual-homed configurations with diverse fiber paths are available. Options include active/active load balancing or active/standby failover. BGP deployments enable automatic prefix failover.
  </Accordion>

  <Accordion title="What equipment do I need?">
    BGP requires a router with BGP-4 support. Static and L2 handoffs work with standard enterprise firewalls and routers. Technical specs provided during quoting to ensure compatibility.
  </Accordion>

  <Accordion title="How long does installation take?">
    Standard installations complete in 20-30 business days where fiber exists. New construction timelines vary based on permitting. Milestone updates provided throughout.
  </Accordion>

  <Accordion title="Do you support SD-WAN integration?">
    Yes. L2 Transport handoff is purpose-built for SD-WAN edge devices. Transparent Layer 2 delivery ensures seamless integration with leading SD-WAN platforms.
  </Accordion>
</Accordions>

***

Get Connected [#get-connected]

Email &#x2A;*[sales@hatsnet.io](mailto:sales@hatsnet.io)** with your site address and bandwidth requirements. We respond within one business day.

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Hats EPN | SD-WAN as a Service





**Hats EPN (Enterprise Private Network)** is a fully managed private connectivity service that delivers enterprise-grade WAN without the operational overhead of building and maintaining your own SD-WAN infrastructure.

<Callout type="info" title="Why Managed WAN?">
  Get all the benefits of Software-Defined Connectivity-traffic segmentation, predictable latency, and multi-site orchestration-without hiring specialized network engineers or managing complex edge devices.
</Callout>

Why Managed WAN? [#why-managed-wan]

Most enterprises don't want to become networking companies. Here's how Hats EPN compares to the DIY approach:

| Aspect                      | Self-Built SD-WAN                           | Hats EPN (Managed)              |
| --------------------------- | ------------------------------------------- | ------------------------------- |
| **Setup Time**              | 3-6 months (hardware, config, testing)      | Days to weeks                   |
| **Expertise Required**      | Senior network engineers on staff           | Zero - we handle everything     |
| **Ongoing Ops**             | 24/7 NOC, patch management, troubleshooting | Included in service             |
| **Hardware Investment**     | CAPEX for edge appliances                   | OPEX only - no hardware to buy  |
| **Multi-vendor Complexity** | Integrating firewalls, SD-WAN, monitoring   | Single unified service          |
| **Scaling**                 | Manual provisioning, capacity planning      | On-demand bandwidth adjustments |
| **SLA Accountability**      | You own all uptime risk                     | 99.99% SLA with Hats Network    |

**Bottom line**: Focus on your business while we manage the network infrastructure.

Delivery Models [#delivery-models]

<Tabs defaultValue="routed" className="mt-6">
  <TabsList>
    <TabsTrigger value="routed">
      <Route />

      Routed Private Network
    </TabsTrigger>

    <TabsTrigger value="switched">
      <Cable />

      Switched Private Network
    </TabsTrigger>

    <TabsTrigger value="underlay">
      <Network />

      SD-WAN Underlay
    </TabsTrigger>
  </TabsList>

  <TabsContent value="routed" className="space-y-3">
    **Managed routed connectivity** for enterprises who want us to handle the core routing infrastructure while they focus on their applications.

    **What You Get**:

    * Software-defined routing with traffic segmentation
    * BGP peering at your edge (optional)
    * Complete traffic isolation between environments
    * Automatic failover and path optimization
    * Predictable latency across our private backbone

    **Best For**:

    * Multi-office WAN with centralized internet breakout
    * Cloud on-ramp integration (AWS, Azure, GCP)
    * Segmented environments (production, development, voice, security zones)
    * Enterprises without deep networking expertise in-house
  </TabsContent>

  <TabsContent value="switched" className="space-y-3">
    **Transparent Ethernet transport** for customers who prefer to manage their own routing stack while we handle the underlying transport.

    **What You Get**:

    * Ethernet handoff at each site (VLAN-tagged)
    * Single broadcast domain across all locations
    * You control all IP addressing and routing protocols
    * Transparent transport for multicast and custom protocols
    * MAC learning and forwarding managed by Hats

    **Best For**:

    * High-availability router pairs with VRRP/HSRP
    * Customer-managed SD-WAN appliances requiring L2 handoff
    * Legacy applications requiring flat Layer-2 adjacency
    * Organizations with existing networking teams
  </TabsContent>

  <TabsContent value="underlay" className="space-y-3">
    **Stable transport foundation** for enterprises running their own SD-WAN, SASE, or custom overlay solutions.

    **What You Get**:

    * Stable IP transport with measurable, consistent latency
    * No encryption overhead (your overlay handles security)
    * Predictable path characteristics for intelligent path selection
    * Dual-stack IPv4/IPv6 support
    * Clean handoff to your edge devices

    **Best For**:

    * SD-WAN fabric underlay (any vendor)
    * SASE architecture foundation
    * Custom overlay with proprietary encryption requirements
    * Hybrid WAN combining private transport with internet backup
  </TabsContent>
</Tabs>

Architecture [#architecture]

<Infographic
  code="infographic hierarchy-mindmap-branch-gradient-capsule-item
width 980
height 660
data
  title Managed Private WAN
  desc Hats EPN centralizes policy in the core, then extends deterministic handoffs to each connected site LAN.
  root
    label Hats EPN Core
    icon monitor
    children
      - label Hong Kong Edge
        icon check-circle
        children
          - label Hong Kong LAN
            icon plug
      - label Tokyo Edge
        icon check-circle
        children
          - label Tokyo LAN
            icon plug
      - label Singapore Edge
        icon check-circle
        children
          - label Singapore LAN
            icon plug
      - label Cloud On-Ramp
        icon cloud
        children
          - label AWS Direct Connect
            icon cloud
          - label Azure ExpressRoute
            icon cloud
          - label GCP Cloud Interconnect
            icon cloud
theme
  palette #1783ff #f26a3d #00a6a6 #f0a020 #5c6f82"
/>

**Simple connection model**: We manage the complex backbone. You get a clean handoff at each site.

Use Cases [#use-cases]

Multi-Site Enterprise WAN [#multi-site-enterprise-wan]

Connect offices, factories, and data centers with consistent performance. Hats EPN provides the backbone while your IT team focuses on applications, not routing tables.

* **Manufacturing**: Connect global production facilities to ERP systems
* **Retail**: Link stores to centralized POS and inventory systems
* **Professional Services**: Reliable video conferencing between offices

Cloud Access [#cloud-access]

Direct, optimized paths to major cloud providers. Your cloud workloads perform like they're on your local network.

* **AWS Direct Connect** integration
* **Azure ExpressRoute** connectivity
* **Multi-cloud** architectures with consistent performance

Critical Workloads [#critical-workloads]

When latency and jitter directly impact revenue, Hats EPN delivers the predictability that internet connections can't match.

* **Financial Trading**: Sub-50ms latency between trading venues
* **Healthcare**: Reliable DICOM image transfers for telemedicine
* **Real-time Collaboration**: Consistent video and voice quality

<Callout type="tip" title="Benchmarks for Critical Workloads">
  > <u>TU-T</u> guidance commonly uses \<150ms one-way delay for highly interactive voice tasks.

  > <u>Microsoft’s Teams</u> connectivity test passes with UDP latency \<100ms, UDP jitter \<30ms, and UDP packet loss \<1%.

  Sources: [ITU-T Rec. G.114 (05/2003)](https://www.itu.int/rec/dologin_pub.asp?lang=e\&id=T-REC-G.114-200305-I!!PDF-E), [Microsoft 365 network connectivity test tool](https://learn.microsoft.com/en-us/microsoft-365/enterprise/office-365-network-mac-perf-onboarding-tool?view=o365-worldwide)
</Callout>

Service Specifications [#service-specifications]

| Specification       | Routed               | Switched      | Underlay      |
| ------------------- | -------------------- | ------------- | ------------- |
| **Handoff Type**    | BGP or Static        | 802.1Q VLAN   | IP or BGP     |
| **Routing Control** | Hats-managed         | You manage    | Minimal       |
| **MTU**             | 1500 or 9000 (Jumbo) | 1500 or 9000  | 1500 or 9000  |
| **Multicast**       | Available            | Transparent   | No            |
| **IPv6**            | Native               | Native        | Native        |
| **SLA**             | 99.99% uptime        | 99.99% uptime | 99.99% uptime |

Traffic Segmentation & QoS [#traffic-segmentation--qos]

Built-in traffic classification without complex configuration:

| Traffic Class | Priority    | Treatment            | Typical Use               |
| ------------- | ----------- | -------------------- | ------------------------- |
| **Real-Time** | Highest     | Guaranteed bandwidth | Voice, video conferencing |
| **Critical**  | High        | Low latency queue    | Trading systems, ERP      |
| **Business**  | Standard    | Standard forwarding  | Email, SaaS applications  |
| **Default**   | Best effort | Standard forwarding  | Bulk transfers, backups   |

**No VRF configuration needed** - traffic segmentation is handled by our platform based on your requirements.

FAQ [#faq]

<Accordions>
  <Accordion title="What's the difference between Routed and Switched Private Network?">
    **Routed Private Network**: We manage the routing. You connect your edge device to our network, and we handle all the complexity of path selection, traffic segmentation, and optimization. Best for organizations that want "it just works."

    **Switched Private Network**: We provide transparent Ethernet transport between your sites. Your routers see each other as directly connected on the same LAN segment. You manage all IP addressing and routing. Best for organizations with existing networking teams who want control.

    Choose Routed for simplicity. Choose Switched if you have specific routing protocol requirements or need Layer-2 adjacency between sites.
  </Accordion>

  <Accordion title="Can I use Hats EPN as an SD-WAN underlay?">
    Yes. Our SD-WAN Underlay option is purpose-built for this use case. We provide stable, measurable IP transport with consistent latency characteristics-exactly what SD-WAN solutions need for accurate path selection.

    Benefits of using Hats EPN as your underlay:

    * **Consistent baselines**: Your SD-WAN makes better path decisions with stable metrics
    * **Reduced tunnel flapping**: No internet jitter causing unnecessary failover events
    * **Guaranteed bandwidth**: Private backbone capacity independent of internet congestion
    * **Simplified ops**: We maintain the underlay; you focus on overlay policies

    Compatible with all major SD-WAN platforms including VeloCloud, Fortinet, Palo Alto, Cisco, and open-source solutions.
  </Accordion>

  <Accordion title="How does traffic segmentation work?">
    Hats EPN uses Software-Defined Connectivity to create isolated traffic domains. Think of them as virtual networks that share physical infrastructure but never intersect.

    Common segmentation patterns we support:

    * **Environment Isolation**: Production, staging, and development as separate virtual networks
    * **Traffic Type Separation**: Voice traffic on its own segment with priority treatment
    * **Security Zones**: Guest networks, corporate data, and PCI-compliant traffic fully isolated
    * **Departmental Segments**: Different business units with controlled interconnectivity

    You define the segments. We handle the implementation-no complex configuration on your end.
  </Accordion>

  <Accordion title="What does 'fully managed' actually mean?">
    With Hats EPN, you don't need network engineers on staff:

    **We Handle**:

    * Core network design and operation
    * Routing protocol management and optimization
    * 24/7 monitoring and incident response
    * Capacity planning and scaling
    * Software updates and security patches
    * Peering and upstream relationships

    **You Handle**:

    * Your edge devices (routers, firewalls)
    * Your internal LAN
    * Your application configuration

    You get a simple handoff at each site. Everything behind that is our responsibility.
  </Accordion>

  <Accordion title="What are the latency commitments?">
    We provide baseline latency measurements during onboarding. Typical inter-PoP latencies on our private backbone:

    <Callout type="success" title="Global Backbone RTT (Realtime)">
      For the full auto-updated RTT matrix across our PoPs (Backbone measurements), see: [Backbone
      Latency Matrix](/docs/network/latency)
    </Callout>

    | Route                 | Latency  |
    | --------------------- | -------- |
    | Hong Kong ↔ Tokyo     | 35-45ms  |
    | Hong Kong ↔ Singapore | 35-45ms  |
    | Tokyo ↔ Los Angeles   | 90-110ms |
    | Frankfurt ↔ Amsterdam | 5-8ms    |

    Our SLA covers latency variance (jitter) and packet loss, not just uptime. Because we control the backbone, we can guarantee performance characteristics that internet-based solutions cannot match.
  </Accordion>

  <Accordion title="Can we connect to cloud providers?">
    Yes. Hats EPN integrates with major cloud platforms:

    * **AWS**: Direct Connect via our partner locations
    * **Microsoft Azure**: ExpressRoute connectivity
    * **Google Cloud**: Dedicated Interconnect
    * **Alibaba Cloud**: Express Connect

    Cloud connectivity is integrated into your private network segments, creating seamless hybrid cloud architecture. Your cloud resources appear as just another site on your WAN.
  </Accordion>

  <Accordion title="How quickly can we get started?">
    Typical deployment timeline:

    | Phase            | Timeline  | Details                            |
    | ---------------- | --------- | ---------------------------------- |
    | **Discovery**    | 1-2 days  | Requirements, topology design      |
    | **Contracting**  | 3-5 days  | Service order, terms               |
    | **Provisioning** | 5-15 days | Circuit activation, cross-connects |
    | **Testing**      | 1-2 days  | Validation, acceptance             |
    | **Go-Live**      | -         | Production traffic                 |

    **Total: 2-4 weeks** from signature to production - significantly faster than traditional carrier services.

    Existing Hats Network customers can often add EPN services in days, leveraging existing infrastructure.
  </Accordion>
</Accordions>

Getting Started [#getting-started]

<Steps>
  <Step title="Schedule a Consultation">
    Tell us about your sites, bandwidth needs, and any cloud connectivity requirements. We'll design
    a topology that fits.
  </Step>

  <Step title="Review Your Design">
    We provide a detailed proposal including topology, SLAs, and pricing. No surprises.
  </Step>

  <Step title="Provisioning">
    We handle circuit coordination, equipment installation, and configuration. You provide the
    cross-connect details.
  </Step>

  <Step title="Go Live">
    We validate end-to-end connectivity, establish baseline performance metrics, and hand over
    operational documentation.
  </Step>
</Steps>

<Callout type="tip" title="Ready to simplify your WAN?">
  Contact our team: &#x2A;*[sales@hatsnet.io](mailto:sales@hatsnet.io)**

  Include:

  * Number of sites and locations
  * Bandwidth requirements per site
  * Preferred delivery model (Routed/Switched/Underlay)
  * Cloud connectivity needs
  * Target deployment regions
</Callout>

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Hats GO - Load Up. Lock In.





> You'll need a new excuse for your K.D.R.

***

The Problem [#the-problem]

Lag kills more than bad aim.

Every competitive player knows the pain: you peek first, you die first. Your crosshair was on their head-server says otherwise. That 80ms routing through three different carriers? It's giving your opponent the advantage.

**Peeker's disadvantage.** Bad hit registration. Rollback eating your inputs. When milliseconds decide matches, your network is part of your loadout.

Most "gaming" solutions add hops, encryption overhead, or tunnel you through oversubscribed servers. That's not optimization-it's a handicap.

***

What Is Hats GO (Gaming Optimized)? [#what-is-hats-go-gaming-optimized]

**Hats GO** is competitive-grade routing.

Not a VPN. Not a tunnel. Not a magic button.

We build direct network paths to major game infrastructure through strategic Internet Exchange peering. Your traffic hits the game server faster because we eliminated the detours-not because we wrapped it in extra layers.

* **Direct IX peering** at HKIX, JPIX, DE-CIX, AMS-IX
* **BGP-level optimization**-no encryption overhead
* **Sub-30ms or nothing** to major competitive servers
* **99.99% uptime** with automatic failover

Think of it as a dedicated lane on the information highway. Same road, better path.

***

The Numbers [#the-numbers]

When your ping is the difference between clutching and choking.

<Callout type="success" title="Global Backbone RTT (Realtime)">
  For the full auto-updated RTT matrix across our PoPs (Backbone measurements), see: [Backbone
  Latency Matrix](/docs/network/latency)
</Callout>

| Route                 | Standard Path (Ping / Loss) | Hats GO (Ping / Loss) | Overall Improvement |
| --------------------- | --------------------------- | --------------------- | ------------------- |
| Hong Kong → Singapore | 60\~200ms / 4\~8%           | 30\~45ms / \<1%       | \~74%               |
| Hong Kong → Tokyo     | 80\~150ms / 3\~7%           | 45\~55ms / \<1%       | \~60%               |
| Hong Kong → Taipei    | 30\~80ms / 2\~5%            | 15\~30ms / \<1%       | \~61%               |
| Hong Kong → Seattle   | 150\~200ms / 8\~15%         | 130\~150ms / 1\~2%    | \~28%               |
| Hong Kong → Frankfurt | 200\~270ms / 10\~20%        | 150\~170ms / 1\~3%    | \~42%               |
| Hong Kong → Sydney    | 150\~200ms / 8\~12%         | 120\~150ms / 1\~2%    | \~30%               |

<Callout type="info" title="How We Calculate Improvement">
  To account for the severe impact of packet loss on gaming (rubberbanding and desync), we calculate the improvement based on **Effective Latency**, which factors in the penalty of packet retransmission.

  **Variables:**

  * **$E$**: Effective Latency
  * **$P$**: ICMP Latency (Base Ping)
  * **$L$**: Packet Loss Rate
  * **$std$ / $go$**: Subscripts for Standard Path and Hats GO

  **1. Effective Latency Base Formula:**

  ```math
  E = \frac{P}{1 - L}
  ```

  **2. Improvement Calculation:**

  ```math
  I = \left(1-\frac{P_{go} \times (1 - L_{std})}{P_{std} \times (1 - L_{go})} \right) \times 100\%
  ```
</Callout>

\* Measured from HKG PoP. Your mileage varies based on location and last-mile conditions.

***

How It Works [#how-it-works]

<Tabs defaultValue="direct-peering" className="mt-6">
  <TabsList>
    <TabsTrigger value="direct-peering">
      <Handshake />

      Direct Peering
    </TabsTrigger>

    <TabsTrigger value="route-engineering">
      <Route />

      Route Engineering
    </TabsTrigger>

    <TabsTrigger value="qos">
      <Gauge />

      QoS
    </TabsTrigger>
  </TabsList>

  <TabsContent value="direct-peering" className="space-y-3">
    We don't ask intermediaries for favors. We're plugged directly into the same exchanges where game publishers host their infrastructure.

    | IX Location | Publishers On-Site              |
    | ----------- | ------------------------------- |
    | **HKIX**    | Tencent, Garena, Riot SEA       |
    | **JPIX**    | Square Enix, Sega, Bandai Namco |
    | **DE-CIX**  | EU game servers, Ubisoft EU     |
    | **AMS-IX**  | Valve EU, EA EU                 |

    Fewer hops = fewer milliseconds = fewer excuses.
  </TabsContent>

  <TabsContent value="route-engineering" className="space-y-3">
    Our BGP policies don't leave routing to chance.

    * **Community tagging** - Game traffic gets priority paths
    * **Local preference** - IX routes over transit, always
    * **AS-path control** - Inbound optimization for symmetric latency

    This is network engineering at the protocol level. No added latency from encryption or tunnel termination.
  </TabsContent>

  <TabsContent value="qos" className="space-y-3">
    Raw speed means nothing if your packets arrive inconsistently.

    | Metric           | Target |
    | ---------------- | ------ |
    | Packet Loss      | \<0.1% |
    | Jitter           | \<2ms  |
    | Latency Variance | \<5%   |

    Stable ping matters more than low average ping. A consistent 35ms beats a spiky 25-60ms every time.
  </TabsContent>
</Tabs>

***

By Game Type [#by-game-type]

Different games. Different demands. Same standard.

<Infographic
  code="infographic chart-column-simple
data
  title Competitive Latency Ceiling (ms)
  desc Lower ceilings indicate genres where route quality and direct peering matter most.
  values
    - label FTG
      value 16
      icon gamepad-2
    - label FPS
      value 30
      icon crosshair
    - label BR Games
      value 40
      icon plane
    - label MOBA
      value 50
      icon swords
theme
  palette #ff5f1f #ff9300 #1783ff #00a6a6"
/>

| Genre             | Examples             | Target Latency | Why It Matters                                                             |
| ----------------- | -------------------- | -------------- | -------------------------------------------------------------------------- |
| **FPS**           | CS2, Valorant, Apex  | Sub-30ms       | Peeker's advantage. Hit reg. When every frame counts in a duel.            |
| **Fighting**      | SF6, Tekken 8, GBVSR | Sub-16ms       | Rollback netcode works best with minimal delay. Frame-perfect inputs.      |
| **MOBA**          | Dota 2, LoL          | Sub-50ms       | Skill-shot timing. Team fight responsiveness. No stutter on clutch plays.  |
| **Battle Royale** | PUBG, Fortnite       | Sub-40ms       | Position updates. Hit registration at range. Circle closure reaction time. |

<Callout type="tip" title="References for Competitive Latency Ceilings">
  Epic describes \<=20ms as “good” latency, 20-100ms as “acceptable”, and >=100ms as “poor” for Fortnite.

  Source: [Epic Games: Understanding latency or ping in Fortnite](https://www.epicgames.com/help/fortnite-battle-royale-c-202300000001636/technical-support-c-202300000001719/fortnite-latency-and-ping-troubleshooting-a202300000010042)
</Callout>

***

Coverage [#coverage]

Hats GO routes available at these PoPs:

**Asia-Pacific**

* Hong Kong (HKG)
* Tokyo (NRT)
* Singapore (SIN)

**Europe**

* Frankfurt (FRA)
* Amsterdam (AMS)

**North America**

* Los Angeles (LAX)
* New York (NYC)

Contact sales for availability in your region.

***

FAQ [#faq]

<Accordions>
  <Accordion title="Is this a VPN?">
    No. Hats GO operates at the network routing level-BGP peering and direct IX connections. There's no encryption overhead, no tunnel wrapping, no additional hops. Your traffic travels natively over optimized paths, not through a middleman server.
  </Accordion>

  <Accordion title="Will this lower my ping?">
    If you're on a suboptimal route to game servers where we have peering, yes-often significantly. If you're already geographically close with good routing, improvements may be marginal. We can run latency tests from your location before you commit.
  </Accordion>

  <Accordion title="Does this work with my ISP?">
    Hats GO is delivered through BGP peering or IP transit arrangements-typically for businesses, data centers, or esports venues. Residential access varies by region and ISP partnership. Contact sales to discuss your specific setup.
  </Accordion>

  <Accordion title="Which games benefit most?">
    Any latency-sensitive multiplayer title. FPS and fighting games see the most dramatic improvements due to their frame-level precision requirements. MOBAs and battle royales benefit from consistent routing and reduced jitter.
  </Accordion>

  <Accordion title="Is this legal for competitive play?">
    Yes. Hats GO uses standard internet routing protocols-no packet manipulation, no artificial lag reduction, no circumvention of regional restrictions. It's optimized connectivity, not a circumvention tool.
  </Accordion>

  <Accordion title="Can I try it first?">
    Qualified business customers can request latency measurements and trials. Contact our sales team with your location and target game servers-we'll show you the numbers before you buy.
  </Accordion>
</Accordions>

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Hats Network Services





Hats Network Services [#hats-network-services]

We offer an enterprise-grade connectivity portfolio designed for businesses and professionals of all sizes.

***

>

Service Catalog [#service-catalog]

<Cards>
  <Card title="Hats EPN" description="SD-WAN as a Service. Multi-site private connectivity with traffic segmentation and guaranteed SLAs." href="/docs/services/enterprise-private-network" icon="🏢" />

  <Card title="Hats BDL" description="Enterprise DIA. Committed bandwidth with flexible handoff options for offices and critical endpoints." href="/docs/services/business-dedicated-line" icon="🔌" />

  <Card title="Hats PUL" description="Performance IP. Low-jitter access for latency-sensitive professionals and distributed teams." href="/docs/services/premium-user-line" icon="⚡" />

  <Card title="Hats GO" description="Competitive Gaming Routes. Sub-30ms paths to publishers via direct IX peering." href="/docs/services/gaming-optimized" icon="🎮" />

  <Card title="Hats SR" description="Media-Grade Connectivity. High-throughput infrastructure for 4K/8K delivery with CDN peering." href="/docs/services/streaming-ready" icon="📡" />
</Cards>

***

Service Selection Decision Tree [#service-selection-decision-tree]

Unsure which service fits your needs? Follow this decision tree:

<Infographic
  code="infographic hierarchy-tree-tech-style-capsule-item
width 980
height 600
data
  title Service Selection Decision Tree
  desc Start with footprint analysis, then navigate through control model, endpoint profile, and traffic specialization to find your optimal service mix.
  root
    label Start Here
    value 100
    icon compass
    children
      - label Footprint Analysis
        value 80
        icon map
        children
          - label Single Site
            value 60
            icon home
            children
              - label Need SLA-backed Internet
                value 40
                icon shield
                children
                  - label Hats BDL
                    value 20
                    icon plug
              - label Need Low-jitter Access
                value 40
                icon zap
                children
                  - label Hats PUL
                    value 20
                    icon user
          - label Multi-Site (4+)
            value 60
            icon building
            children
              - label Hats EPN
                value 40
                icon globe
      - label Traffic Specialization
        value 80
        icon target
        children
          - label Gaming / Esports
            value 60
            icon gamepad-2
            children
              - label Hats GO
                value 40
                icon trophy
          - label Media / OTT
            value 60
            icon tv
            children
              - label Hats SR
                value 40
                icon film
      - label Final Service Mix
        value 80
        icon layers
        children
          - label Combine as Needed
            value 60
            icon link
            children
              - label All Services Stack
                value 40
                icon check-circle
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020 #5c6f82"
/>

Quick Selection Guide [#quick-selection-guide]

<Tabs defaultValue="saas" className="mt-6">
  <TabsList>
    <TabsTrigger value="saas">
      <Building2 />

      SaaS & Enterprise
    </TabsTrigger>

    <TabsTrigger value="multi-site">
      <Network />

      Multi-Site Business
    </TabsTrigger>

    <TabsTrigger value="creative">
      <Palette />

      Creative Teams
    </TabsTrigger>

    <TabsTrigger value="gaming">
      <Gamepad2 />

      Gaming & Esports
    </TabsTrigger>

    <TabsTrigger value="media">
      <Film />

      Media Platforms
    </TabsTrigger>
  </TabsList>

  <TabsContent value="saas" className="space-y-3">
    **Primary Need**: Secure, segmented connectivity between offices and cloud.

    | Requirement             | Recommended    |
    | ----------------------- | -------------- |
    | 3+ sites, private mesh  | Hats EPN       |
    | Single site, SLA-backed | Hats BDL       |
    | Hybrid cloud handoff    | Hats EPN + BGP |
  </TabsContent>

  <TabsContent value="multi-site" className="space-y-3">
    **Primary Need**: Reliable inter-office connectivity that scales.

    | Site Count     | Recommended               |
    | -------------- | ------------------------- |
    | 2–3 locations  | Hats BDL (point-to-point) |
    | 4+ locations   | Hats EPN (full mesh)      |
    | Remote workers | Hats PUL (endpoints)      |
  </TabsContent>

  <TabsContent value="creative" className="space-y-3">
    **Primary Need**: Low-jitter access to cloud suites and collaboration tools.

    | Use Case              | Recommended |
    | --------------------- | ----------- |
    | Video editing teams   | Hats PUL    |
    | Animation/VFX studios | Hats BDL    |
    | Distributed teams     | Hats EPN    |
  </TabsContent>

  <TabsContent value="gaming" className="space-y-3">
    **Primary Need**: Minimal latency to game servers and tournament infra.

    | Organization               | Recommended           |
    | -------------------------- | --------------------- |
    | Esports teams & facilities | Hats GO               |
    | Tournament organizers      | Hats GO + BGP         |
    | Gaming cafes/chains        | Hats BDL + GO profile |
  </TabsContent>

  <TabsContent value="media" className="space-y-3">
    **Primary Need**: Consistent throughput for high-bitrate video.

    | Scale               | Recommended             |
    | ------------------- | ----------------------- |
    | Individual creators | Hats PUL                |
    | OTT platforms       | Hats SR                 |
    | CDN operators       | IP Transit + SR profile |
  </TabsContent>
</Tabs>

***

Service Architecture Overview [#service-architecture-overview]

<Infographic
  code="infographic hierarchy-structure
width 980
height 700
data
  title Service Architecture Stack
  desc Every commercial offer is a packaged view of the same AS203314 backbone, with different access, policy, and workload tuning.
  items
    - label Access Layer
      children
        - label Hats BDL
          desc Branch / HQ DIA
        - label Hats PUL
          desc Low-jitter endpoints
    - label Performance Layer
      children
        - label Hats GO
          desc Gaming-optimized routes
          children
            - label Direct IX Peering
            - label Sub-30ms Paths
            - label Publisher Connectivity
        - label Hats SR
          desc Streaming-ready delivery
          children
            - label CDN Peering
            - label 4K/8K Support
            - label Sustained Throughput
    - label Managed WAN Layer
      children
        - label Hats EPN
          desc Multi-site private mesh
          children
            - label SD-WAN as Service
            - label Traffic Segmentation
            - label Cloud On-Ramp
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020 #5c6f82"
/>

Why Enterprise-Grade [#why-enterprise-grade]

| Feature   | Best-Effort Internet     | Hats Enterprise-Grade        |
| --------- | ------------------------ | ---------------------------- |
| Bandwidth | Shared, oversubscribed   | Committed CIR                |
| Routing   | Cost-optimized, variable | BGP-controlled deterministic |
| Peering   | Multi-transit hops       | Direct IX at 15+ exchanges   |
| SLA       | None                     | 99.99% uptime with credits   |
| Support   | Business hours           | 24/7 NOC                     |

***

Frequently Asked Questions [#frequently-asked-questions]

<Accordions>
  <Accordion title="What's the difference between Hats BDL and standard business broadband?">
    Hats BDL provides **committed bandwidth**, you receive 100% of purchased capacity 100% of the time. Standard broadband is "best effort" and commonly oversubscribed (for example, cable/DSL can be 50:1+ on business tiers, while Metro Ethernet is often 10:1 or less).

    BDL also includes symmetric speeds, static IPs, SLA guarantees, and BGP peering options.

    <Callout type="tip" title="Sources">
      Oversubscription examples and typical ratios: [CTC Technology & Energy: All Mbps Are Not Created
      Equal (Connectivity Performance
      Factors)](https://www.ctcnet.us/wp-content/uploads/2014/02/CTC-ConnectivityPerformanceFactorsBrief0213141.pdf)
    </Callout>
  </Accordion>

  <Accordion title="Can I start with one service and upgrade later?">
    Yes. Many customers begin with Hats BDL for individual sites, then migrate to Hats EPN as they add locations. Handoff types remain consistent during migration.

    Contact your account manager to discuss upgrade paths.
  </Accordion>

  <Accordion title="Does Hats EPN replace my existing SD-WAN?">
    Hats EPN provides network-layer traffic engineering without overlay complexity. For customers requiring SD-WAN appliances, we partner with vendors to deliver managed solutions over our backbone.
  </Accordion>

  <Accordion title="What's the typical installation timeline?">
    | Service  | Timeline             |
    | -------- | -------------------- |
    | Hats PUL | 5\~10 business days  |
    | Hats BDL | 15\~30 business days |
    | Hats EPN | 30\~45 business days |

    Expedited installation available in select markets.
  </Accordion>

  <Accordion title="Which PoPs support GO and SR profiles?">
    Gaming and Streaming profiles are available at our IX-connected locations:

    **Asia-Pacific**: Hong Kong, Tokyo, Singapore\
    **Europe**: Frankfurt, Amsterdam, London\
    **North America**: Los Angeles, New York, Ashburn

    Contact sales for current availability and latency estimates.
  </Accordion>
</Accordions>

***

Get Started [#get-started]

<Callout type="tip" title="Contact Sales">
  Unsure which service fits your requirements? Our team can analyze your current connectivity and recommend the optimal configuration.

  **[sales@hatsnet.io](mailto:sales@hatsnet.io)** - include your current setup, bandwidth needs, and any performance issues.
</Callout>

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Hats PUL | Performance IP for Gaming & Cloud





What It Is [#what-it-is]

**Hats PUL (Premium User Line)** is Performance IP connectivity - not a VPN, not a proxy, not a tunnel.

We give your traffic a direct lane. Through our own AS203314 backbone, direct IX peering with major gaming publishers and cloud providers, and intelligent routing that cuts out the congested public internet.

Think of it as upgrading from a shared road to a dedicated expressway. Same destination. Entirely different ride.

***

The Problem [#the-problem]

Standard ISP routes are built for **capacity**, not **latency**.

Your packets zigzag through tier-1 carriers, hit overcrowded peering points, and get routed through whatever's cheapest - not what's fastest. The result?

* Jitter that ruins your spray control
* 150ms+ routes to servers that should be 30ms away
* Inconsistent hit registration
* Rubberbanding at the worst possible moment

You're paying for "gigabit" but getting lag spikes that no bandwidth can fix.

***

The Solution [#the-solution]

**Direct Peering. Intelligent Routing. Performance IP.**

<Infographic
  code="infographic compare-binary-horizontal-badge-card-arrow
width 980
height 520
data
  title Routing Path Comparison
  desc Hats PUL removes detours and stabilizes egress for latency-sensitive traffic.
  compares
    - label Standard Broadband
      icon globe
      children
        - label Shared upstream chain
          icon users
        - label Variable egress policy
          icon timer
        - label ~80 ms with bursty jitter
          icon chart-bar
    - label Hats PUL
      icon zap
      children
        - label AS203314 access edge
          icon radio
        - label Direct IX Peering
          icon handshake
        - label ~30 ms with low jitter
          icon check-circle
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

| What We Do                 | What It Means                                                                               |
| -------------------------- | ------------------------------------------------------------------------------------------- |
| **Direct IX Peering**      | Traffic enters our network and exits directly at major IX points. No middlemen. No detours. |
| **AS203314 Backbone**      | Our own infrastructure. Our own routes. Full control over path selection.                   |
| **Gaming-Optimized Paths** | Routes tuned for UDP consistency, not just TCP throughput.                                  |
| **Multi-Hub Redundancy**   | Automatic failover between our PoPs without dropping your session.                          |

The outcome? Sub-30ms latency to major gaming and cloud regions. Consistent ping. Predictable performance.

***

By The Numbers [#by-the-numbers]

<Callout type="success" title="Global Backbone RTT (Realtime)">
  For the full auto-updated RTT matrix across our PoPs (Backbone measurements), see: [Backbone
  Latency Matrix](/docs/network/latency)
</Callout>

Real-world latency from our core PoPs to major destinations:

| Route                 | Standard ISP | Hats PUL | Improvement  |
| --------------------- | ------------ | -------- | ------------ |
| Singapore → Hong Kong | 45-60ms      | 28-32ms  | \~40% faster |
| Tokyo → Seoul         | 55-70ms      | 32-38ms  | \~45% faster |
| Frankfurt → Amsterdam | 25-35ms      | 12-15ms  | \~55% faster |
| Los Angeles → Tokyo   | 140-160ms    | 95-105ms | \~30% faster |

Your mileage may vary, but the pattern doesn't: &#x2A;*shorter paths, lower latency, less jitter.**

<Callout type="tip" title="References for Competitive Latency Ceilings">
  Epic describes \<=20ms as “good” latency, 20-100ms as “acceptable”, and >=100ms as “poor” for Fortnite.

  Source: [Epic Games: Understanding latency or ping in Fortnite](https://www.epicgames.com/help/fortnite-battle-royale-c-202300000001636/technical-support-c-202300000001719/fortnite-latency-and-ping-troubleshooting-a202300000010042)
</Callout>

***

Who It's For [#who-its-for]

Competitive Gamers [#competitive-gamers]

Stop losing duels to ping. Get the stable connection your mechanics deserve.

Streamers & Content Creators [#streamers--content-creators]

Low-latency gaming + stable upstream. No more "sorry, lag" moments on stream.

Remote Workers [#remote-workers]

Video calls that don't stutter. File transfers that don't crawl. A connection that just works.

Cloud Developers [#cloud-developers]

Direct, low-latency access to AWS, Azure, GCP regions. Faster deploys. Snappier terminals.

***

How It Works [#how-it-works]

1. **Connect** - Route your traffic through our nearest PoP
2. **Optimize** - Our edge routers select the best path in real-time
3. **Win** - Lower latency, reduced jitter, consistent performance

No software to install. No configuration headaches. Just better routing.

***

FAQ [#faq]

Is this a VPN? [#is-this-a-vpn]

**No.** Hats PUL is Performance IP connectivity through route optimization. We don't encrypt your traffic, change your IP location, or provide "privacy" features. We're a network infrastructure service - not a VPN provider.

Will this work with my ISP? [#will-this-work-with-my-isp]

Yes. Hats PUL operates at the network layer and is compatible with any internet connection. We optimize the path *after* your traffic reaches our edge.

Does it support all games? [#does-it-support-all-games]

Any game that uses standard IP networking will benefit from lower latency and reduced jitter. We don't modify game traffic - we just deliver it faster.

What's the catch? [#whats-the-catch]

No catch. We're a network operator (AS203314) with our own infrastructure. We peer directly with major networks. That's the edge - literally.

How do I get started? [#how-do-i-get-started]

Contact our team for availability in your region. We'll set up your Performance IP connection and get you routed through our backbone.

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Hats SR | Media-Grade Connectivity





Big stream? Major release? Crank up your bandwidth on the fly.

Hats SR delivers **Media-Grade Connectivity** - sustained throughput engineered for professional 4K/8K workflows, not speed test bragging rights.

<Callout type="info" title="Why Quality Matters">
  According to [Conviva's 2025 research](https://www.conviva.ai/2025-state-of-digital-experience-report/):

  > Every 1% degradation in Quality of Experience leads to a 1% increase in customer churn.

  Buffering and quality switches directly impact viewer retention and revenue.
</Callout>

***

The Problem: Burst vs. Sustained [#the-problem-burst-vs-sustained]

Standard networks are built for speed tests, not real-world streaming:

<Tabs defaultValue="oversubscription" className="mt-6">
  <TabsList>
    <TabsTrigger value="oversubscription">
      <BarChart3 />

      Oversubscription
    </TabsTrigger>

    <TabsTrigger value="peak-hour">
      <Clock />

      Peak Hour Congestion
    </TabsTrigger>

    <TabsTrigger value="burst-sustained">
      <Activity />

      Burst vs Sustained
    </TabsTrigger>
  </TabsList>

  <TabsContent value="oversubscription" className="space-y-3">
    **The Problem**: Consumer ISPs heavily oversubscribe bandwidth, assuming not everyone uses it simultaneously.

    **The Impact**:

    * Bitrate throttling (4K drops to 720p)
    * Buffering during high-action scenes
    * Inconsistent quality throughout playback

    **Our Solution**: Hats SR provisions dedicated capacity with direct CDN peering to maintain quality during peak demand periods.
  </TabsContent>

  <TabsContent value="peak-hour" className="space-y-3">
    **The Problem**: During peak hours (7-11 PM), ISP peering links to CDNs often run at saturation.

    **The Impact**:

    * Higher latency to cache
    * Increased startup time
    * Frequent quality switches

    **Our Solution**: We maintain low-latency paths to major CDNs via IX peering at STUIX, NL-IX, DE-CIX, HKIX, and more.
  </TabsContent>

  <TabsContent value="burst-sustained" className="space-y-3">
    **The Problem**: Speed tests measure burst capacity, but 8K streaming requires sustained 100Mbps+ for hours.

    **The Impact**:

    * High initial speed, then quality drops
    * Inability to maintain 8K streams
    * Degradation during long viewing sessions

    **Our Solution**: Our network is provisioned for sustained throughput with redundant upstream providers.
  </TabsContent>
</Tabs>

***

What Is "Hats SR"? [#what-is-hats-sr]

Hats SR (Streaming Ready) is **Media-Grade Connectivity** - network infrastructure engineered for sustained bandwidth delivery, not burst speed tests.

Unlike consumer internet that optimizes for occasional speed test snapshots, Hats SR is built for:

* **Sustained throughput** - hours of consistent 4K/8K delivery
* **Direct CDN peering** - bypassing congested transit paths
* **Low jitter** - stable bitrates without quality switches
* **Redundant architecture** - 99.99% uptime SLA

***

Bandwidth Requirements [#bandwidth-requirements]

Professional media workflows have specific bandwidth needs:

<Infographic
  code="infographic chart-column-simple
data
  title Committed Capacity per Stream (Mbps)
  desc CIR starting points for sustained streams. Add headroom for redundancy and multi-bitrate ladders.
  values
    - label HD (1080p)
      value 5
      icon film
    - label Full HD
      value 10
      icon monitor-play
    - label 4K (2160P)
      value 35
      icon tv
    - label 4K HDR
      value 50
      icon sun
    - label 8K (4320P)
      value 80
      icon monitor
theme
  palette #1783ff #00c2ff #00a6a6 #f26a3d #f0a020"
/>

| Quality | Resolution  | Recommended Bandwidth | Typical Bitrate\* |
| ------- | ----------- | --------------------- | ----------------- |
| HD      | 1080p       | 10-15 Mbps            | 5-9 Mbps          |
| Full HD | 1080p60     | 15-25 Mbps            | 9-15 Mbps         |
| 4K      | 2160p       | 25-50 Mbps            | 15-25 Mbps        |
| 4K HDR  | 2160p + HDR | 40-60 Mbps            | 20-35 Mbps        |
| 8K      | 4320p       | 100+ Mbps             | 50-80+ Mbps       |

Hats SR handles multiple concurrent 4K/8K streams without degradation - whether you're delivering to an OTT platform or producing live content.

<Callout type="tip" title="Sources">
  Bandwidth/bitrate reference points: [Netflix-recommended internet
  speeds](https://help.netflix.com/en/node/306), [YouTube Live - Bitrate
  Recommendations](https://support.google.com/youtube/answer/2853702?hl=en)
</Callout>

***

CDN Peering [#cdn-peering]

We maintain direct peering with major content delivery networks through Internet Exchange points:

| CDN                  | IX Access Points            | Key Benefit                              |
| -------------------- | --------------------------- | ---------------------------------------- |
| Netflix Open Connect | SIX Seattle, AMS-IX, others | 4K/8K content served locally             |
| Google Global Cache  | Multiple IX locations       | YouTube and Google services optimization |
| Akamai               | Multiple IX locations       | Broad content delivery network access    |
| Cloudflare           | Multiple IX locations       | Content delivery + performance           |
| Amazon CloudFront    | Multiple IX locations       | AWS-originated content optimization      |
| Fastly               | Multiple IX locations       | Real-time content and API optimization   |

<Callout type="tip" title="IX Advantage">
  Our presence at major Internet Exchange points (HKIX, JPIX, DE-CIX, AMS-IX) provides direct paths to CDN infrastructure that would otherwise require multiple transit hops.
</Callout>

***

Use Cases [#use-cases]

Video Platforms [#video-platforms]

Deliver consistent 4K/8K experiences to global audiences:

* OTT platforms
* Media publishers
* VOD services
* Corporate video delivery

Live Production [#live-production]

Reliable upload capacity for professional live production:

* 4K60 streaming to multiple platforms simultaneously
* Stable bitrates for broadcast-quality productions
* Low-latency options for interactive streaming
* Remote production workflows

Enterprise Streaming [#enterprise-streaming]

Clear video communication without quality degradation:

* All-hands meetings in 4K
* Executive broadcasts
* Town halls and events
* Microsoft Teams, Zoom, Google Meet optimization

***

Technical Specifications [#technical-specifications]

| Specification     | Value                              |
| ----------------- | ---------------------------------- |
| Minimum Bandwidth | 100 Mbps sustained per stream (8K) |
| Global Capacity   | 1 Tbps+ backbone capacity          |
| Jitter            | \<2ms (95th percentile)            |
| Packet Loss       | \<0.1% (normal operation)          |
| IX Peering        | HKIX, JPIX, DE-CIX, AMS-IX, STUIX  |
| Uptime SLA        | 99.99% with automatic failover     |

<Callout type="success" title="Global Backbone RTT (Realtime)">
  For the full auto-updated RTT matrix across our PoPs (Backbone measurements), see: [Backbone
  Latency Matrix](/docs/network/latency)
</Callout>

***

Regional Availability [#regional-availability]

Hats SR is available at PoPs with high CDN density:

**Asia-Pacific**: Hong Kong, Tokyo, Singapore

**North America**: Los Angeles, New York

**Europe**: Frankfurt, Amsterdam

Additional locations available upon request.

***

FAQ [#faq]

<Accordions>
  <Accordion title="What makes Hats SR different from business internet?">
    Business internet plans often still follow consumer oversubscription models. Hats SR is explicitly provisioned for sustained bandwidth with direct CDN peering, ensuring your 4K/8K streams maintain quality even during peak hours.
  </Accordion>

  <Accordion title="How do you handle peak hours?">
    We provision peering capacity based on peak-hour demand projections and leverage multiple upstream providers with automatic failover. This maintains performance during the 7-11 PM period when networks often degrade.
  </Accordion>

  <Accordion title="Can Hats SR support live production workflows?">
    Yes. Hats SR is ideal for live production with stable upload bandwidth for multi-platform streaming. For ultra-low latency requirements (remote production, live shopping), contact us to discuss specific needs.
  </Accordion>

  <Accordion title="What happens if a CDN has issues?">
    Our network maintains diverse paths through multiple IX locations and upstream providers. If one CDN experiences issues, traffic can often be rerouted to alternative paths or CDNs.
  </Accordion>

  <Accordion title="Do you offer dedicated infrastructure?">
    For enterprise customers with high-volume requirements, we can discuss custom infrastructure solutions. Contact sales to explore options for your use case.
  </Accordion>

  <Accordion title="What is the minimum commitment?">
    Hats SR service requirements vary by region and bandwidth needs. Contact our sales team for a custom quote based on your specific requirements.
  </Accordion>
</Accordions>

***

<Callout type="warning" title="Ready to Crank It Up?">
  **[Contact Sales](#contact)** to discuss Hats SR for your media workflows.

  Hats Network Inc. (AS203314): &#x2A;[Imagine a world where network connectivity is seamless, secure and accessible to everyone.](/about)*
</Callout>


# Asia Transit





🌏 Asia Transit [#-asia-transit]

<div id="pop-hkg3" className="scroll-mt-24" />

🇭🇰 Hong Kong (HKG3) [#-hong-kong-hkg3]

<img alt="Hong Kong" src="https://static.hatsnet.io/images/banner/hongkong.png" width="1920" height="1280" />

<Callout type="info">
  [View HKG3 Routes in BGP Tools →](https://bgp.tools/prefix/2602:2a3:300::/41#connectivity)
</Callout>

| Feature          | Value | Notes                    |
| ---------------- | ----- | ------------------------ |
| IPv4 IP-Transit  | ✅     | Do not use for Anti-DDoS |
| IPv6 IP-Transit  | ✅     | Connected AS174 & AS6939 |
| Automated Filter | ❌     | Prefix list required     |

Upstream [#upstream]

* Hytron Network Limited ([AS202662](https://bgp.tools/as/202662))
  * Cogent Communications ([AS174](https://bgp.tools/as/174))
  * Hurricane Electric ([AS6939](https://bgp.tools/as/6939))
  * CDN77 ([AS60068](https://bgp.tools/as/60068))

Peering [#peering]

* 🇭🇰 HKIX (Hong Kong) &#x2A;(via AS202662)*
* 🇭🇰 Equinix IX (Hong Kong) &#x2A;(via AS202662)*

***

<div id="pop-sin1" className="scroll-mt-24" />

🇸🇬 Singapore (SIN1) [#-singapore-sin1]

<img alt="Singapore" src="https://static.hatsnet.io/images/banner/singapore.png" width="1920" height="1250" />

| Feature          | Value | Notes                    |
| ---------------- | ----- | ------------------------ |
| IPv4 IP-Transit  | ✅     | Do not use for Anti-DDoS |
| IPv6 IP-Transit  | ✅     | Connected AS2914 & AS174 |
| Automated Filter | ❌     | Prefix list required     |

Upstream [#upstream-1]

* Nearoute Limited ([AS51847](https://bgp.tools/as/51847))
  * Cogent Communications ([AS174](https://bgp.tools/as/174))
  * NTT ([AS2914](https://bgp.tools/as/2914))

Peering [#peering-1]

* 🇸🇬 Equinix IX (Singapore) &#x2A;(via Upstream)*

***

<div id="pop-tyo2" className="scroll-mt-24" />

🇯🇵 Tokyo, Japan (TYO2) [#-tokyo-japan-tyo2]

<img alt="Tokyo" src="https://static.hatsnet.io/images/banner/tokyo.png" width="1920" height="1280" />

| Feature          | Value | Notes                             |
| ---------------- | ----- | --------------------------------- |
| IPv4 IP-Transit  | ✅     | Do not use for Anti-DDoS          |
| IPv6 IP-Transit  | ✅     | Connected AS2914 & AS174 & AS3491 |
| Automated Filter | ❌     | Prefix list required              |

Upstream [#upstream-2]

* Nearoute Limited ([AS51847](https://bgp.tools/as/51847))
  * Cogent Communications ([AS174](https://bgp.tools/as/174))
  * NTT ([AS2914](https://bgp.tools/as/2914))
  * PCCW Global ([AS3491](https://bgp.tools/as/3491))

Peering [#peering-2]

* 🇯🇵 Equinix IX (Tokyo) &#x2A;(via Upstream)*

***

<div id="pop-tpe2" className="scroll-mt-24" />

🇹🇼 Taipei (TPE2) [#-taipei-tpe2]

<img alt="Taipei" src="https://static.hatsnet.io/images/banner/taipei.png" width="1920" height="1280" />

<Callout type="warn">
  This location is currently **Closed** for new IP-Transit orders. [View Route Map in BGP Tools
  →](https://bgp.tools/prefix/2a0c:9a40:95e3::/48#connectivity)
</Callout>

| Feature          | Value | Notes                   |
| ---------------- | ----- | ----------------------- |
| IPv6 IP-Transit  | ✅     | Connected AS6939        |
| IPv6 to Cogent   | ❌     | Unconnected AS174       |
| Automated Filter | ✅     | Supports RPKI ROA / IRR |

Upstream [#upstream-3]

* Hurricane Electric ([AS6939](https://bgp.tools/as/6939))

Peering [#peering-3]

* 🇹🇼 STUIX (Taipei)


# Europe Transit





🇪🇺 Europe Transit [#-europe-transit]

<Infographic
  code="infographic compare-binary-horizontal-badge-card-arrow
width 980
height 520
data
  title Europe Market Snapshot
  desc Amsterdam and Frankfurt share upstream pairs, but filtering and peering differ operationally.
  compares
    - label Amsterdam
      icon map-pin
      children
        - label Direct HE + iFog
          icon check-circle
        - label Cogent via AS34927
          icon check-circle
        - label Automated filters enabled
          icon shield
    - label Frankfurt
      icon map-pin
      children
        - label Direct HE + iFog
          icon check-circle
        - label Cogent via AS34927
          icon check-circle
        - label Prefix list required
          icon clipboard
theme
  palette #1783ff #00a6a6 #f26a3d #f0a020"
/>

<div id="pop-ams" className="scroll-mt-24" />

🇳🇱 Amsterdam, NL (AMS) [#-amsterdam-nl-ams]

<img alt="Amsterdam" src="https://static.hatsnet.io/images/banner/amsterdam.jpg" width="1920" height="1282" />

<Callout type="info">
  [View AMS Route Map in BGP Tools →](https://bgp.tools/prefix/2a0c:9a40:95e3::/48#connectivity)
</Callout>

| Feature          | Value | Notes                      |
| ---------------- | ----- | -------------------------- |
| IPv6 IP-Transit  | ✅     | Direct Connected to AS6939 |
| IPv6 to Cogent   | ✅     | Reachable via AS34927      |
| Automated Filter | ✅     | Supports RPKI ROA / IRR    |

Upstream [#upstream]

* Hurricane Electric ([AS6939](https://bgp.tools/as/6939))
* iFog GmbH ([AS34927](https://bgp.tools/as/34927))

Peering [#peering]

* 🇳🇱 NL-IX (Amsterdam)

***

<div id="pop-fra" className="scroll-mt-24" />

🇩🇪 Frankfurt, DE (FRA) [#-frankfurt-de-fra]

<img alt="Frankfurt" src="https://static.hatsnet.io/images/banner/frankfurt.png" width="1920" height="1080" />

<Callout type="info">
  [View FRA Routes in BGP Tools →](https://bgp.tools/prefix/2a0c:9a40:95e2::/48#connectivity)
</Callout>

| Feature          | Value | Notes                      |
| ---------------- | ----- | -------------------------- |
| IPv6 IP-Transit  | ✅     | Direct Connected to AS6939 |
| IPv6 to Cogent   | ✅     | Reachable via AS34927      |
| Automated Filter | ❌     | Prefix list required       |

Upstream [#upstream-1]

* Hurricane Electric ([AS6939](https://bgp.tools/as/6939))
* iFog GmbH ([AS34927](https://bgp.tools/as/34927))

Peering [#peering-1]

* 🇩🇪 Loc-IX (Frankfurt)


# IP Transit Services







<Callout type="info" title="IP Transit from AS203314">
  Hats Network Inc. provides **high-quality IP-Transit** services with diverse upstream connectivity across Asia and Europe. Our network features:

  * **Multi-homed** upstream connectivity (Cogent, NTT, HE, PCCW)
  * **IPv4 and IPv6** dual-stack support
  * **Competitive pricing** with flexible commit options
  * **24/7 NOC** support for critical issues
</Callout>

Transit Ordering Flow [#transit-ordering-flow]

<Infographic
  code="infographic sequence-ascending-stairs-3d-underline-text
width 980
height 500
data
  title Transit Ordering Flow
  desc Transit orders move from market selection to commercial sizing, then into physical turn-up and BGP activation.
  sequences
    - label Pick Market
      desc Match latency targets to Asia or Europe footprint
      icon map
    - label Size Commit
      desc Define bandwidth, AF, BGP policy needs
      icon chart-bar
    - label Arrange Handoff
      desc Build cross-connect or tunnel for activation
      icon link
    - label Turn Up BGP
      desc Exchange prefixes, validate with NOC
      icon settings
  order asc
theme
  palette #f26a3d #1783ff #00a6a6 #f0a020"
/>

Available Locations [#available-locations]

We currently offer IP-Transit at the following locations:

| Continent | Country     | City          | Datacenter | Status |
| --------- | ----------- | ------------- | ---------- | ------ |
| Europe    | Netherlands | Amsterdam     | TBD        | Open   |
| Asia      | Hong Kong   | Tseung Kwan O | HKG3       | Open   |
| Asia      | Singapore   | Singapore     | SIN1       | Open   |
| Asia      | Japan       | Tokyo         | TYO2       | Open   |
| Asia      | Taiwan      | Taipei        | TPE2       | Closed |

How to Order [#how-to-order]

<Steps>
  <Step>
    Choose Your Location [#choose-your-location]

    Review our [Asia](/docs/transit/asia) and [Europe](/docs/transit/europe) transit pages to find the location that best fits your needs.

    Consider factors such as:

    * **Latency requirements** to your target markets
    * **Upstream diversity** available at each location
    * **IPv4 vs IPv6** availability
  </Step>

  <Step>
    Contact Sales [#contact-sales]

    Send an email to [sales@hatsnet.io](mailto:sales@hatsnet.io) with the following information:

    * Company name and ASN
    * Desired location and bandwidth requirements
    * Estimated commit level
    * BGP communities or special routing requirements
  </Step>

  <Step>
    Setup & Turn-up [#setup--turn-up]

    Once your order is confirmed, our team will:

    1. Provision the cross-connect or tunnel
    2. Establish BGP sessions
    3. Announce your prefixes
    4. Provide 24/7 NOC contact information
  </Step>
</Steps>

Location Details [#location-details]

<Cards>
  <Card title="Asia Transit" icon="<IconWorld className=&#x22;w-5 h-5&#x22; />" description="Hong Kong, Singapore, Tokyo, and Taipei locations with connections to major Asian IXs." href="/docs/transit/asia" />

  <Card title="Europe Transit" icon="<IconMapPin className=&#x22;w-5 h-5&#x22; />" description="Amsterdam and Frankfurt locations with diverse European connectivity." href="/docs/transit/europe" />
</Cards>

Technical Specifications [#technical-specifications]

<Callout type="default" title="Standard Features">
  All IP-Transit services include:

  * **BGP Communities** for traffic engineering
  * **RPKI/IRR filtering** (where available)
  * **Looking glass** access for route verification
  * **Real-time** traffic graphs
  * **Email** notifications for maintenance windows
</Callout>

Supported Protocols [#supported-protocols]

| Protocol | Support  | Notes                          |
| -------- | -------- | ------------------------------ |
| IPv4     | Full     | Available at all locations     |
| IPv6     | Full     | Native dual-stack              |
| BGP-4    | Full     | Standard and large communities |
| BFD      | Optional | For faster convergence         |

Upstream Networks [#upstream-networks]

Our network is multi-homed to major Tier-1 and Tier-2 providers:

* **Cogent Communications** (AS174)
* **Hurricane Electric** (AS6939)
* **NTT Communications** (AS2914)
* **PCCW Global** (AS3491)
* **iFog GmbH** (AS34927)

Pricing [#pricing]

<Callout type="warn">
  Pricing varies by location and commit level. Please [contact our sales team](mailto:sales@hatsnet.io) for a custom quote.
</Callout>

Support [#support]

For technical support or questions about our IP-Transit services:

* **Sales:** [sales@hatsnet.io](mailto:sales@hatsnet.io)
* **NOC:** [noc@hatsnet.io](mailto:noc@hatsnet.io)