Peering vs transit in one paragraph

Peering vs transit comes down to how traffic leaves your server and reaches the rest of the internet. Transit is paid connectivity that delivers packets anywhere through providers we buy from. Peering is a deliberate exchange between networks, often without settlement, at places where both sides agree it helps. On a LogicWeb VPS or dedicated server, you already receive transit through us, plus any peering we maintain where it is useful. You do not manage those sessions yourself, and an Internet Exchange port is not something you enable on a small plan.

1. When you order a VPS or dedicated server, packets leave on a default route we provide. That path is transit we purchased, combined with peering we already run where it is worth it. You do not configure those BGP sessions.
2. If you need to announce a prefix on your own ASN, that means a BGP session with us, a ROA, and a prefix we have agreed to carry. That still is not an IX port on your account.
3. If you need a specific peering with a particular network or exchange, that is a planned project and a direct conversation with us. It is not a control-panel toggle or a quick ticket asking why traceroute shows a transit hop.

What your plan already includes

We buy transit and peer where it makes sense so your packets leave cleanly. You get a working default route, not a looking-glass login to our core. Two A records in two cities are DNS failover, not peering. The NIC on your VPS carries a default route; that is not “your transit” in the operator sense. Clear wording helps when you open a ticket late at night. People sometimes ask why a small VPS has no IX port. That feature is simply not part of that product.

When peering is worth discussing

Talk about peering when you already have an ASN, a prefix, and a real reason a given network should exchange with you. You are not on a small VPS asking for AMS-IX as a checkbox. You are ready to treat the work as a project with capacity and policy in mind. Peering is not automatically faster. A congested peer can be slower than quiet paid transit. If you run BGP with us, send the prefix, your ASN, and the network you want to reach differently. If you are on a VPS without BGP, the honest answer is that you already have transit.

Paths, tickets, and what you bought

A looking glass shows the path you have; it does not provision a new peering. Traceroute that goes via a transit hop is normal product behavior, not a bug. If you want a path reviewed, paste an mtr from your side and we will compare from ours. Questions like “why aren’t we peered with X” belong on a different desk. Write down what you actually purchased: a VPS, a BGP session, or a custom peering project. Those three requests should not share one subject line. A small VPS with solid transit is a good product. An IX port is a different one. Order the first only if that is what you need, and open the second kind of ticket only when you are ready for that project.