# What does "same-IP failover" actually mean, and is it a real differentiator?

I keep hearing this term "same-IP failover" from a couple of SD-WAN vendors during demos, and I want to make sure I understand it before it becomes a checkbox item in my RFP. From what I gather, it means your public IP doesn't change when your internet circuit fails over to a backup connection — so VoIP calls, VPN sessions, etc. don't drop. Is that actually how it works in practice, or is this more of a marketing term that requires a bunch of BGP setup behind the scenes to pull off? Would love to hear from anyone who's actually tested this in a real failover event, not just a sales demo.

##### Post Metadata
- Posted at: 20 days ago
- Net upvotes: 1


## Comments
### Comment 1

Good question, because "same-IP failover" gets used loosely and not every vendor implements it the same way.

Here's the mechanism, at least for how we do it at Bigleaf: your public IP address isn't assigned by your ISP at all — it's issued from our own gateway infrastructure. All of your traffic gets tunneled from your site to the nearest Bigleaf gateway, and that's where it actually connects to the broader internet. Because the IP lives on our side of that tunnel rather than being tied to whichever ISP circuit is currently active, switching circuits during a failure or degradation event doesn't change the IP at all — the tunnel just gets rerouted to a healthier circuit underneath it. From the perspective of a VoIP call, a VPN tunnel, or a cloud app session, nothing happened.

On the BGP question specifically: you're right that some vendors' version of this does require you to run your own BGP setup — advertising your own address space, dealing with ISP cooperation, maintaining it going forward. That's real infrastructure and real ongoing complexity, and it's fair to be skeptical of anyone who glosses over that. Our approach is meant to function as an alternative to that, not a repackaging of it — the IP block comes from our infrastructure, so there's no BGP session for you to stand up or maintain, and it applies automatically to whatever's running over the tunnel rather than needing per-application policy configuration.

Worth being precise about scope, too: this only covers traffic that's actually running through the tunnel to our gateways. It's not something you bolt onto an existing multi-WAN router as a feature flag — it's a function of the architecture, which is exactly why it's worth actually testing rather than taking as a spec-sheet claim on either side. In practice, this ends up mattering for more than VoIP — VPN tunnels, Microsoft 365 sessions, POS and payment processing connections, and anything else that treats a mid-session IP change as a dropped connection all benefit the same way.

Happy to go deeper on any specific failure scenario if it's useful for your evaluation. A couple of resources if you want the longer version:

Same-IP Address Failover — the mechanism explained in more depth, including a comparison against dual-WAN and carrier SD-WAN approaches.
https://www.bigleaf.net/same-ip-address-failover/

Bigleaf vs. Failover — a closer look at why standard failover setups drop sessions in the first place.
https://www.bigleaf.net/blog/bigleaf-vs-failover/

##### Comment Metadata
- Posted at: 19 days ago
- Author title: Digital Marketing Manager




## Related Product
[Bigleaf Networks](https://www.g2.com/products/bigleaf-networks/reviews)

## Related Category
[SD-WAN](https://www.g2.com/categories/sd-wan)

## Related discussions
- [How well does Trello scale into a larger team?](https://www.g2.com/discussions/1-how-well-does-trello-scale-into-a-larger-team)
  - Posted at: over 13 years ago
  - Comments: 6
- [Can we please add a new section](https://www.g2.com/discussions/2-can-we-please-add-a-new-section)
  - Posted at: over 13 years ago
  - Comments: 0
- [Quantifiable benefits from implementing your CRM](https://www.g2.com/discussions/quantifiable-benefits-from-implementing-your-crm)
  - Posted at: over 13 years ago
  - Comments: 4