Independently operated · AS7201 · multihomed
Network Edge runs AS7201 as an independent, multihomed Internet network — BGP transit, colocation, waves and point-to-point Layer 2 for operators who need more than a plain Internet connection.
Full tables, partial routes or a default. Bring your own ASN and prefixes and we propagate them.
Explore IP TransitCabinets, cages and partial racks in five data centers across Michigan and Missouri.
Explore ColocationTransparent Ethernet between sites, data centers and exchange points — your frames, your VLANs.
Explore Layer 2Dedicated 10G and 100G optical wavelengths between facilities, nationwide at select locations.
Explore WavesWhat we do
Network Edge sells the parts of the Internet that other providers bundle away from you: the routing, the space and the transport.
BGP transit on AS7201 with full tables, partial routes or a default route. Announce your own prefixes, use your own ASN, and take a hand-off anywhere from 100M to 100G.
Cabinets, partial racks and cages across five data centers in Michigan and Missouri, with A+B power, cross connects and AS7201 on-net in every one.
Transparent Ethernet circuits between your sites, data centers and exchange points. Your VLANs and your frames pass end to end — we stay out of your Layer 3.
Independent BGP network
Plenty of "IP transit" on the market is a Layer 2 hand-off into one upstream carrier. Every packet takes that carrier’s path, inherits that carrier’s outages and follows that carrier’s policy.
Network Edge operates AS7201 as its own autonomous system. Traffic entering our network becomes part of a routing domain with its own policy, its own filtering, its own traffic engineering and its own interconnection relationships.
Independent routing policy. Import and export policy, prefix filtering and route validation are ours to set — not inherited from an upstream carrier’s product tier.
Public Internet peering
AS7201 participates at Internet exchange points across the United States, establishing direct BGP relationships instead of pushing every packet down a paid transit path.
No presence at multiple common sites, no minimum traffic ratio, no mandatory contract. If there is a reasonable technical benefit to either network, we want the session.
Read the peering policyUpstream transit provides global reachability; exchange and private interconnection provide directness. Together they give AS7201 path diversity a single-provider design cannot.
See the networkWhere an exchange is not the right fit, we can build direct network-to-network interconnection with your ASN instead.
Discuss an interconnectRouting security
A transit provider that accepts anything is a hazard. Our policy is built to keep invalid announcements and accidental route leaks out of the global table.
Route origin validation checks whether an autonomous system is actually authorized to originate a given prefix.
Machine-readable routing policy, so customer and peer filters can be generated automatically from published objects.
Customer sessions accept explicitly authorized prefixes. We do not blindly take whatever arrives on a BGP session.
Import and export policy governs which routes may enter or leave each individual relationship.
Who we serve
Our customers are typically running infrastructure, not a branch office — networks that announce their own prefixes and run their own BGP.
Questions
No. If you operate your own ASN and IP space we will run BGP with you and propagate your prefixes. If you do not, we can deliver a default route, static routing or provider-assigned addressing where applicable, and help you move to your own resources later.
No. AS7201 is operated as an Internet network in its own right, with its own routing policy, upstream relationships, Internet exchange presence and customer BGP sessions. Traffic entering AS7201 has multiple potential paths to the wider Internet rather than a single carrier.
Yes. Dual-stack is delivered over the same physical port, normally as a separate BGP session per address family. The same routing policy, prefix filtering and origin validation apply to both.
Most likely. We maintain an open peering policy with no requirement for multiple common locations, minimum traffic ratios or a peering contract. Send a peering request through the contact form and we will get a session up.
We build your prefix filters from the routing policy you publish — your IRR objects and your ROAs — and apply RPKI-based origin validation. Send us the prefix list you intend to announce and we will confirm the filter before turn-up.
Tell us your ASN, prefixes, ports and locations. An engineer — not a call-center script — will come back with a design and a number.
