Open the Tunnels page in my.cubepath.com to view your point-to-point network tunnels and BGP connections.
What a tunnel is
A tunnel is a point-to-point link between CubePath and your own infrastructure. Each end is a peer: one CubePath IP Peer and one Client IP Peer. Traffic routes between your remote network and CubePath over that dedicated link, with optional BGP for dynamic route exchange.
The Tunnels list
| Column | What it shows |
|---|---|
| Connection | The tunnel endpoints, local IP ↔ remote IP |
| Peers | The CubePath IP and the Client IP forming the two ends |
| MTU | The maximum transmission unit configured for the tunnel |
| BGP | Whether dynamic routing via BGP is enabled |
| Status | Active, Deploying or Deactivated |
| Description | An optional label |
NoteIf you have no tunnels yet, the page shows "No tunnels found". Tunnels appear here once provisioned.
TipThe MTU is worth knowing before you debug anything. A tunnel adds encapsulation overhead, so the usable MTU is lower than 1500. The classic symptom of getting it wrong is that small packets (ping, SSH handshakes) work fine while larger transfers hang — clamp MSS on your side if you see that.
Getting a tunnel
Tunnels are set up together with CubePath rather than self-served from the dashboard. Open a ticket from my.cubepath.com with the remote endpoint, the IP space you want to route, and whether you need BGP. Once configured, the tunnel appears in this list and moves to Active.
BGP communities
If you run BGP over the tunnel, the communities that control local preference, blackholing, scrubbing, export and AS-path prepending are the same ones we accept on an IP Transit port. They are documented in full in the BGP communities reference.