Route Policy in Action: Managing Multicloud Prefix Limits

Estimated reading time: 4 minutes

Part 2 of Our Route Policy Series

The first post in this series introduced the Virtual Networks Route Policy feature in Internet2 Insight Console and explored three key use cases: protecting BGP peers from max prefix limitations, preventing route leaks, and shaping traffic through attribute modification. These reflect real-world operational needs that research and education (R&E) network operators are actively navigating as cloud connectivity architectures grow in scale and complexity.

Now, let’s dive deep into practical examples that show how to use Route Policy to manage prefix advertisements in a multicloud environment while staying within cloud provider limits. The scenario below is one that Internet2 member institutions have experienced firsthand, and it’s the kind of challenge Route Policy can address before it becomes an incident.

The Scenario

Consider a university with the following architecture:

• Campus network: Multiple subnets across departments (10.0.0.0/8 address space with 150+ individual /16 and /24 subnets)
• AWS connection: Private (or transit) Virtual Interface via Internet2 Cloud Connect (100 prefix limit per address family)
• Azure connection: ExpressRoute via Internet2 Cloud Connect
• Internet2 Cloud Router: Serving as the central routing point in an Internet2 Virtual Network with Route Policy enabled

The challenge is that AWS will only accept 100 IPv4 prefixes before shutting down the BGP session. With 150+ subnets on the campus network — and Azure also advertising routes through the Internet2 Cloud Router to AWS for cross-cloud connectivity — there are too many prefixes, which will cause the session to fail.

This is where proactive controls through Route Policy come into play. The following three examples each walk through a specific goal, the policy configuration that achieves it, and what the result looks like in practice.

Example 1: Aggregating Campus Routes for AWS

Goal: Advertise only summarized routes from campus to AWS to stay under the 100-prefix limit.

Policy Configuration:

yaml
version: 1
description: "Campus to AWS - Advertise aggregates only"
statements:
  - description: "Allow campus summary routes"
    match:
      prefix:
        prefixes:
          - "10.0.0.0/12"
          - "10.16.0.0/12"
          - "10.32.0.0/12"
          - "10.48.0.0/12"
        scope: "exact"
    action: "accept"
  
  - description: "Block all more-specific campus routes"
    match:
      prefix:
        prefixes:
          - "10.0.0.0/8"
        scope: "or-longer"
    action: "reject"
  
  - description: "Default deny"
    action: "reject"

What this does: This export policy, applied to the AWS BGP neighbor, only advertises pre-aggregated summary routes to AWS, blocking all the specific /16 and /24 subnets. Instead of 150+ prefixes, AWS receives just four aggregates covering the entire campus space.

Example 2: Limiting Azure Routes to AWS

Goal: Allow only specific Azure prefixes to be advertised to AWS, preventing Azure’s full routing table from consuming the AWS prefix budget.

Policy Configuration:

yaml
version: 1
description: "Azure to AWS - Allow only specific prefixes"
statements:
  - description: "Allow specific Azure virtual networks"
    match:
      prefix:
        prefixes:
          - "172.16.0.0/16"
          - "172.17.0.0/16"
          - "172.18.0.0/16"
        scope: "exact"
      as-path:
        asn: 12076
        position: "neighbor"
    action: "accept"
  
  - description: "Block all other Azure routes"
    match:
      as-path:
        asn: 12076
        position: "passes-through"
    action: "reject"

  - description: "Default deny"
    action: "reject"

What this does: This export policy, applied to the AWS BGP neighbor, filters routes learned from Azure (ASN 12076) to only allow three specific virtual networks through to AWS. All other Azure routes are blocked, ensuring Azure doesn’t consume the limited AWS prefix budget.

Example 3: Combined Campus and Azure Protection

Goal: Create a comprehensive policy that manages both campus and Azure prefixes being advertised to AWS, with a total target of staying under 50 prefixes to leave headroom.

Policy Configuration:

yaml
version: 1
description: "Combined Campus and Azure to AWS - Stay under 50 prefixes"
statements:
  - description: "Advertise campus aggregates (4 prefixes)"
    match:
      prefix:
        prefixes:
          - "10.0.0.0/12"
          - "10.16.0.0/12"
          - "10.32.0.0/12"
          - "10.48.0.0/12"
        scope: "exact"
    action: "accept"
    modifier:
      add-community:
        - "65000:100"
  
  - description: "Advertise critical Azure VNets (3 prefixes)"
    match:
      prefix:
        prefixes:
          - "172.16.0.0/16"
          - "172.17.0.0/16"
          - "172.18.0.0/16"
        scope: "exact"
      as-path:
        asn: 12076
        position: "neighbor"
    action: "accept"
    modifier:
      add-community:
        - "65000:200"
  
  - description: "Block all campus specifics"
    match:
      prefix:
        prefixes:
          - "10.0.0.0/8"
        scope: "or-longer"
    action: "reject"
  
  - description: "Block all other Azure routes"
    match:
      as-path:
        asn: 12076
        position: "passes-through"
    action: "reject"
  
  - description: "Default deny all other routes"
    action: "reject"

What this does: This comprehensive export policy ensures that AWS receives exactly seven prefixes total: four campus aggregates and three specific Azure virtual networks. The policy tags each set with BGP communities for tracking and potential downstream filtering. That’s well under the 100-prefix limit with room for future growth.

Putting It All Together

On the Internet2 Cloud Router, these policies apply as follows:

1. Campus → Internet2 Cloud Router → AWS: Apply Example 1 or Example 3 as an export policy on the AWS BGP neighbor.
2. Azure → Internet2 Cloud Router → AWS: Apply Example 2 or Example 3 as an export policy on the AWS BGP neighbor.
3. Monitor prefix counts: Use Looking Glass inside Insight Console to verify the actual number of prefixes being advertised to AWS.

The key benefit is that even if a campus network grows to 200+ subnets or Azure expands its virtual networks, setting the Route Policy ensures AWS never receives more than the configured number of prefixes. In other words, it doesn’t just solve the problem for the current state of the network; it holds as the environment grows, continuing to protect the BGP session from the dreaded idle state.

Best Practices

The following best practices are worth implementing for any Route Policy:

• Leave headroom: Target 30-50 prefixes when the limit is 100 to accommodate unexpected route additions.
• Use aggregation: Summarize routes to the largest practical aggregates.
• Document exceptions: Keep clear records of which specific routes you’re allowing through and why.
• Tag with communities: Use BGP communities to track route sources for troubleshooting.
• Test configuration: Validate policy syntax using the Insight Console interface before applying to production during a maintenance window.

Next Steps

Ready to get started? Visit the Route Policy documentation for step-by-step guidance through all available configuration options. Then log in to Insight Console to configure your first policy today.

Stay tuned for the final part of this series, which will explore advanced Route Policy scenarios. Those will include traffic engineering with local preference and MED, AS path prepending for failover, and community-based routing strategies.

ICYMI

• Enhancing Cloud Connectivity with Internet2’s Route Policy Feature
• Restoring Critical Cloud Access Through Internet2 Insight Console’s New Route Policy