Full-table BGP transit, on a network that filters its routes.
Wholesale IP transit on AS137492 — multi-homed across two Tier-1 upstreams and PKIX, with RPKI ROA validation, MANRS-aligned filtering and a community set that lets you traffic-engineer without opening a ticket.
Transit, sold the way an engineer would buy it.
IP transit is for customers who run their own AS and want a clean BGP feed: a full v4 and v6 table, MD5 or RFC 8950 next-hop, MED and local-pref handling that doesn't surprise you, and a NOC that can read a route trace without rebooting the conversation. We are multi-homed across two Tier-1 upstreams and present at PKIX, with private peering into the major content networks active in Pakistan.
Sessions are eBGP over your handoff port, MD5-authenticated by default. You announce your prefixes — they must be either authenticated by RPKI ROAs or registered against IRR objects we can validate — and we propagate them to all upstreams and peers. BFD is supported for sub-second failure detection on 10G and 100G ports. Communities cover prepending, scope (no-export to peers / customers / upstreams), blackhole, and graceful shutdown.
Customers we deliver transit to.
Regional ISPs and WISPs
Operators with their own AS who want a second or third upstream for resilience and traffic blending.
DC operators
Carrier-neutral data centres reselling transit to their tenants and needing a BGP session that doesn't go down on planned maintenance.
Content owners and OTT platforms
Local content networks pushing high egress to Punjab eyeballs who want predictable peering and selective announcement scope.
Cloud and hosting providers
Local IaaS/PaaS operators advertising customer prefixes who need a transit that won't drop their RPKI-invalid neighbour's announcements.
Banks and large enterprises with PI space
Organisations holding their own /22 or /23 of provider-independent IPv4 who want a clean dual-stack BGP feed.
Network engineering teams in transition
Customers migrating off a poor incumbent who need a transit they can lab in parallel and cut over with a published session-config sample.
Session and policy details.
| Metric | Target | Notes |
|---|---|---|
| Our AS | AS137492 | PeeringDB AS137492 |
| Address families | IPv4 + IPv6 | Single or split sessions |
| Authentication | MD5 (default) | TCP-AO on request |
| Max prefixes | 1M v4 / 250k v6 | Per peer; tuned per customer |
| BFD | Supported, 50/150 ms | On 10G+ ports |
| Looking glass | lg.vcloud.com.pk | Public, read-only |
| Metric | Target | Notes |
|---|---|---|
| RPKI | Drop invalids | Per RFC 6811 |
| IRR filtering | RADb / RIPE / APNIC | AS-SET required for >5 prefixes |
| MANRS actions | All four | Anti-spoofing, filtering, coordination, GVA |
| Communities | Prepend / no-export / blackhole | Documented in welcome email |
| DDoS blackhole | 65500:666 → /32 + /128 | Propagated to upstreams |
| Graceful shutdown | GRACEFUL_SHUTDOWN (65535:0) | Both directions |
From quote to live session.
- 01
Pre-flight
Day 0 – 3. ASN, prefixes, IRR/ROA check, max-prefix and policy review.
- 02
Port assignment
Day 3 – 7. Cross-connect or LR optic delivery if you're in our DC, or PE port if you're on-net via fibre.
- 03
Session up
Day 7 – 10. eBGP brought up in test mode, prefixes audited, communities tested.
- 04
Production
Day 10 – 14. Customer announces, traffic ramps, monthly 95th billing starts.
What network engineers ask.
What's your filtering posture?
How is billing structured?
Do you support flowspec?
What's the smallest commit you'll quote?
Can I peer privately with you (instead of buying transit)?
What's your response time on a routing incident?
Is IPv6 a default or an option?
Send us your AS-SET, prefixes and target commit.
We'll respond with a port quote, the welcome email content for your records, and an estimate of next-hop latency from the closest of our PoPs.