Skip to main content

Mixed Provider Anycast

When you announce the same prefix from NetActuate alongside other network providers, you create a mixed-provider anycast deployment. This gives you broader geographic coverage and provider redundancy, but requires careful configuration to ensure predictable routing behavior.

Why Mixed Provider Anycast​

Mixed-provider anycast is common for:

  • DNS infrastructure -- authoritative or recursive DNS servers deployed across multiple providers for maximum availability
  • CDN edge nodes -- content delivery from the nearest provider edge, regardless of which provider serves it
  • DDoS resilience -- an attack on one provider does not take down the service if other providers continue to announce the prefix

How BGP Path Selection Works​

When your prefix is announced from multiple providers, each upstream network selects the best path based on the standard BGP decision process:

  1. Highest local preference (within a single AS)
  2. Shortest AS path length
  3. Lowest origin type (IGP < EGP < incomplete)
  4. Lowest MED (if paths are from the same neighboring AS)
  5. eBGP over iBGP
  6. Lowest IGP metric to next hop
  7. Lowest router ID

In a mixed-provider scenario, the AS path length is the most influential factor for inter-domain routing. If one provider prepends additional AS hops, that path becomes less preferred globally.

BGP Table Examples​

Symmetric announcement (equal preference)​

If you announce 192.0.2.0/24 from NetActuate (AS 13830) and Provider B (AS 64500) without prepending, upstream networks see:

*> 192.0.2.0/24    via NetActuate    AS path: 13830 65001
*  192.0.2.0/24    via Provider B    AS path: 64500 65001

Both paths have the same AS path length (2 hops). The upstream network selects a path based on lower-priority tiebreakers. This gives you roughly equal global distribution but with less deterministic control.

Asymmetric announcement (primary/backup)​

To make NetActuate the preferred path globally, have Provider B prepend your ASN:

*> 192.0.2.0/24    via NetActuate    AS path: 13830 65001
*  192.0.2.0/24    via Provider B    AS path: 64500 65001 65001 65001

Now the NetActuate path (2 hops) is universally preferred over the Provider B path (4 hops). Provider B only receives traffic if the NetActuate path is withdrawn.

BGP Community Examples​

BGP communities let you signal routing policy to upstream providers. NetActuate supports standard communities for traffic engineering:

Blackhole community​

To trigger upstream blackholing of a prefix under DDoS attack:

route 192.0.2.0/24 via <next-hop> community 13830:666;

No-export community​

To prevent NetActuate from exporting your prefix to its peers (useful when you want the prefix announced only within NetActuate's network):

route 192.0.2.0/24 via <next-hop> community no-export;

AS path prepending via community​

Some configurations use communities to request prepending on the provider side. Check with NetActuate support for the specific community values supported on your sessions.

Best Practices​

Use consistent prefix lengths​

Announce the same prefix length from all providers. If you announce /24 from NetActuate and /23 from another provider, networks that receive both will route based on longest-prefix match, not anycast -- the /24 always wins for half the space.

Coordinate AS path lengths​

Decide in advance which provider should be preferred. Use AS path prepending to create a clear hierarchy. A common pattern:

  • Primary provider: no prepending (AS path length = 2)
  • Secondary provider: prepend 1x (AS path length = 3)
  • Tertiary provider: prepend 2x (AS path length = 4)

Monitor from multiple vantage points​

Use public looking glasses and BGP route collectors to verify how your prefix is seen globally. Tools like RIPE RIS, RouteViews, and bgp.tools show which path different networks prefer.

Test failover before going live​

Before relying on mixed-provider anycast in production:

  1. Announce from all providers.
  2. Withdraw the announcement from your primary provider.
  3. Verify that traffic shifts to the secondary within an acceptable timeframe.
  4. Re-announce from the primary and confirm traffic returns.

Keep ROA records current​

If you use RPKI, ensure your Route Origin Authorizations (ROAs) include all provider ASNs that are authorized to originate your prefix. An invalid ROA can cause your prefix to be filtered by RPKI-enforcing networks.

Next Steps​

Need Help?​

Contact support@netactuate.com or open a support ticket from the portal.