Routing identity
Option one · Own ASN and external routing policy
Your own ASN or another documented routing identity.
Option two · Provider-managed routing
The provider's identity, unless the service says otherwise.
Back to comparisons
SKNK Field Notes · Point by point
Run Your Own ASN or Use Provider-Managed Routing?
This is a decision about operational ownership: who controls the routing identity, who configures BGP, who takes incidents, and who carries the dependencies when the network changes.
Reviewed against public documentation: 2 August 2026
Compare point by point
Every point is concrete work.
Who configures BGP?
Option one · Own ASN and external routing policy
Your team configures and operates BGP with compatible upstreams.
Option two · Provider-managed routing
The provider runs the routing service inside its stated scope.
Who controls the policy?
Option one · Own ASN and external routing policy
You can define the policy you want, subject to upstream acceptance and filtering.
Option two · Provider-managed routing
What can be announced or changed is set by the provider's product and policy.
Who owns the operational work?
Option one · Own ASN and external routing policy
Your team owns the configuration, monitoring, incident response, and coordination.
Option two · Provider-managed routing
Responsibility follows the provider's published service boundary and agreement.
Where this can be a useful starting point
Put the choice back into your actual network.
Research an own-ASN model when you need to define an external routing policy across compatible upstreams.
Provider-managed routing can be simpler when you want the provider to own the routing work inside a documented boundary.
Before an application or change
Settle these questions first.
1
If you leave the provider, does the routing identity (ASN) move with you?
2
Will the provider accept the exact prefix and origin ASN you plan to use?
3
What changes when you add an upstream, change a prefix, or leave the service?
This guide frames the questions; the answers come from the formal pages.
Policies, resource relationships, service boundaries, and upstream filters differ by situation. For price, eligibility, ownership, or service-end questions, use the formal pages and confirm with the responsible party.
SKNK · Sources and scope
Sources and scope for this comparison
Each source supports one kind of conclusion. Source pages, registry records, and routing observations update at different times, so read every result with its source and timestamp.
RIPE Database
Registry and IRR records
Useful for checking
Whether a public object exists for this ASN or prefix, who it is registered to, and who maintains it.
Not enough to prove alone
It cannot tell you whether the route is being announced. An object is not an announcement.
SKNK support policy
Current service boundaries
Useful for checking
What SKNK publicly states about BGP and network-operations responsibility.
Not enough to prove alone
It does not define an upstream provider's acceptance or filtering policy.