Why Your Enterprise Needs Its Own Public IP Subnet — And How BGP Makes It Work

Most Indian enterprises run their entire internet-facing infrastructure on ISP-assigned IP addresses. Think about what that means for a moment. Your company's internet identity — every IP address customers connect to, every DNS record, every VPN endpoint, every mail server — belongs to your ISP, not you. You're building your digital presence on rented ground.

The Problem: You're Renting Your Digital Address

Here's a scenario I've walked into more times than I'd like to count. A company decides to switch ISPs — maybe the current one has poor latency, bad support, or simply isn't competitive on pricing anymore. Reasonable decision. Then their network team realizes what switching actually involves:

• DNS records — every A record, MX record, and PTR record pointing to ISP-assigned IPs needs updating
• Firewall rules — every NAT policy, every VPN tunnel endpoint, every access rule referencing those IPs
• VPN configurations — every remote user, every site-to-site tunnel, every partner connection
• Email authentication — SPF records, DKIM signing, DMARC policies all tied to those IPs
• Client whitelists — every customer, vendor, and partner who has whitelisted your source IPs in their firewalls
• Application configurations — hardcoded IPs in applications, APIs, monitoring systems, SCADA/OT endpoints

The migration takes weeks of planning and hours of downtime. For what? Because the IP addresses were never yours to begin with.

But single-ISP dependency isn't just an inconvenience during migration. It's a live risk every single day.

We've seen a 500-user enterprise lose 14 hours of productivity because their only ISP had a fiber cut on a national highway. No failover. No option. Five hundred people sitting idle while a JCB dug up fiber somewhere in Haryana. The CFO calculated the cost at over ₹18 lakhs in lost billing hours alone — not counting the client SLA penalties that followed.

Then there's IP reputation. When your ISP assigns you addresses from a shared /16 block, you're sharing that reputation with every other customer on that block. When another customer on that range starts sending spam — or worse, gets compromised and becomes part of a botnet — the entire block gets flagged. Your email deliverability drops. Your API calls to cloud services start getting rate-limited. You've done nothing wrong, but you're paying the price for your neighbor's poor security hygiene.

The Solution: Provider Independent (PI) IP Space + BGP

The answer is straightforward, and it's been the standard for serious network operators for decades: get your own IP addresses and announce them yourself using BGP (Border Gateway Protocol).

Let me break down the two types of IP address allocations:

With PI space, here's what happens: you register with APNIC (the Asia-Pacific Network Information Centre — the regional internet registry for India), receive your own /24 (256 IP addresses) and your own ASN (Autonomous System Number). You then announce your IP prefix to the internet via BGP through two or more ISPs simultaneously.

If one ISP goes down — fiber cut, equipment failure, routing issue — BGP automatically withdraws the route through that ISP and traffic reroutes through the surviving link. Typical convergence time: 30 to 90 seconds. No manual intervention. No DNS TTL waits. No panicked phone calls to the ISP. Traffic just flows through the next best path.

5 Reasons This Isn't Optional for Uptime-Critical Organizations

1. ISP Independence

When you own your IPs, switching ISPs is a non-event. You bring up the new ISP link, establish BGP peering, and start announcing your prefix through both providers. Once you've validated the new link, you decommission the old one. Zero downtime. Zero IP changes. Zero reconfiguration of DNS, firewalls, VPNs, or client whitelists.

Real scenario: A financial services firm in Mumbai wanted to move from a legacy ISP to a newer provider with better latency to AWS Mumbai. With PA addresses, this would have been a weekend-long migration. With their own PI space, they completed the transition during business hours — users didn't even notice.

2. Automatic Failover

BGP convergence happens in seconds, not the hours it takes for DNS failover to propagate. When an ISP link fails, BGP peers detect the loss (via keepalive timers or BFD — Bidirectional Forwarding Detection), withdraw the affected routes, and traffic shifts to the surviving path. With BFD enabled, detection can happen in under a second.

Compare this to DNS-based failover, where you're at the mercy of TTL values. Even with a 300-second TTL, you're looking at 5+ minutes of disruption — and many DNS resolvers ignore TTLs entirely, caching for hours.

3. Traffic Engineering

BGP gives you granular control over how traffic enters and leaves your network. With tools like AS path prepending, local preference, MED (Multi-Exit Discriminator), and BGP communities, you can:

• Route latency-sensitive traffic (VoIP, video conferencing, trading platforms) over the lowest-latency link
• Push bulk transfers (backups, large file downloads) over the cheapest link
• Balance load across multiple ISPs based on traffic type, destination, or time of day
• Prefer specific ISPs for specific destination networks (e.g., route AWS traffic over the ISP with direct peering to AWS)

A university we worked with was paying premium rates on both their ISP links. By implementing BGP traffic engineering, they moved 70% of their bulk traffic (OS updates, video streaming, cloud backups) to the cheaper link and kept the premium link for research and academic applications. Same total bandwidth, significantly better performance where it mattered.

4. IP Reputation Control

With your own /24, your IP reputation is entirely in your hands. Your SPF records point to IPs you control permanently. Your DKIM keys sign from addresses that won't change when you switch providers. Your reverse DNS (PTR records) are delegated to your name servers, not your ISP's.

This matters enormously for email deliverability, especially for organizations sending transactional or marketing email at scale. When you share an IP block with hundreds of other ISP customers, one compromised customer can torpedo the reputation of the entire range. With PI space, the only entity that can damage your IP reputation is you.

5. DDoS Mitigation Flexibility

This is the one that most people don't think about until they're under attack. With your own ASN and PI space, you can respond to a DDoS attack by re-announcing your prefix through a scrubbing service — Cloudflare Magic Transit, Akamai Prolexic, or any upstream DDoS mitigation provider. Clean traffic gets forwarded to your origin; attack traffic gets dropped at the scrubbing center.

With ISP-assigned addresses? You're entirely dependent on your ISP's DDoS mitigation capabilities. And if your ISP's response to a volumetric attack is to null-route your IPs to protect their other customers (which many do), you're offline until the attack subsides. Owning your prefix gives you options that ISP-assigned space simply cannot.

Who Should Be Doing This Already

If you're in any of these categories and you're still running on ISP-assigned IPs, this should be on your next quarterly infrastructure review:

Universities & Research Institutions

10,000+ students and faculty generating massive concurrent traffic. Eduroam federation requiring stable IP infrastructure. Research networks with global peering needs — participation in NKN (National Knowledge Network), ERNET, or international research consortia. Many IITs, IISERs, and central universities already have their own ASNs. If your institution doesn't, you're behind.

Hospitals & Healthcare

Patient portals, telemedicine platforms (especially post-ABHA/ABDM integration), PACS imaging systems, and HL7/FHIR interfaces — all depend on continuous connectivity. When a hospital's internet goes down, it's not just inconvenient. Appointment systems, lab report delivery, pharmacy integrations, and teleconsultations all stop. Lives can literally depend on network uptime.

BFSI (Banking, Financial Services, Insurance)

RBI's IT governance framework and business continuity guidelines effectively mandate high-availability networking. BGP multihoming is the standard implementation for meeting these requirements. If your bank's core banking system, UPI interface, or payment gateway runs on a single ISP link with PA addresses, your DR plan has a fundamental gap.

SaaS Companies

Your customers expect 99.99% uptime — that's less than 53 minutes of downtime per year. You can't deliver that on a single ISP connection. And every time you change IPs, every customer who has whitelisted your API endpoints needs to update their firewalls. Own your IPs, and your infrastructure becomes location-independent.

Manufacturing with OT/SCADA

Industrial control systems are notoriously sensitive to IP changes. PLCs, SCADA HMIs, historian servers, and MES interfaces often have hardcoded IP dependencies. Changing an IP address might mean reconfiguring every PLC on a production line — with associated downtime risk in a 24/7 manufacturing environment. PI space eliminates this entirely.

Government & PSUs

Sovereign control over routing is not just a technical preference — it's a national security consideration. Government organizations should not have their routing controlled by a private ISP. Own ASN and PI space give you routing sovereignty and the ability to implement policy-based routing at a national level.

How to Get Started: The APNIC Route

For Indian organizations, APNIC is your regional internet registry. Here's the step-by-step process:

Timeline: The entire process — from APNIC application to live BGP announcement — typically takes 2 to 4 weeks, assuming your ISPs are cooperative with peering setup. The APNIC side is usually the fastest part; ISP provisioning of BGP sessions takes the longest.

What You Need on Your End

The infrastructure requirements are simpler than most people assume:

• A BGP-capable router or firewall — You need a device that can run full BGP with route maps, prefix lists, and community support. FortiGate firewalls, for instance, support complete BGP functionality and combine firewall, SD-WAN, and BGP routing in a single appliance — which simplifies the stack significantly for mid-size deployments.
• Minimum 2 ISP connections — Ideally from different carriers using different physical fiber paths. Having two links from the same carrier over the same fiber duct defeats the purpose.
• A network engineer who understands BGP — Or a managed service partner who can handle the initial setup and ongoing route management. BGP configuration isn't something you want to learn in production.
• Peering agreements with ISPs — Each ISP needs to accept your BGP session and agree to announce your prefix. Most major Indian ISPs (Tata, Airtel, Jio, BSNL) support customer BGP peering.
• IRR registration and RPKI certificates — Both handled through APNIC's member portal. Non-negotiable for responsible BGP operation.

Common Objections (And Why They Don't Hold Up)

The Bottom Line

If your business can't afford 4 hours of internet downtime, you can't afford not to own your IP space. Provider Independent addressing with BGP multihoming isn't bleeding edge — it's been the standard for serious network operators for over two decades. The only reason more Indian enterprises haven't adopted it is inertia and the assumption that "my ISP handles networking."

Your ISP handles their networking. Your network — your uptime, your IP reputation, your routing policy, your DDoS response — should be under your control.

For a detailed implementation guide covering BGP configuration, APNIC registration, and multihoming architecture, visit our BGP & Public IP Subnet service page.

If you're evaluating BGP multihoming for your organization and want a straightforward assessment of what's involved, talk to Ogma's networking team. We've deployed this for enterprises, universities, and data centers across India — we'll tell you exactly what you need and what you don't.