Google Meet’s Enterprise Content Delivery Network (Meet eCDN) rules

September 30, 2025
Meet eCDN custom rules improvements for new and existing configurations

What's changing
In order to improve the experience of admins managing Google Meet’s Enterprise Content Delivery Network (Meet eCDN) rules, we’re updating how the “Custom Rules” peering policy works in some cases, and how assigned networks are surfaced in the MQT eCDN network table. Understanding these changes will allow customers to make full use of those improvements.

Overlapping IP ranges
Please note you will only see this change if you have defined overlapping IP ranges. For example, if you have defined a large range that’s allowed but including some smaller ranges that should be blocked within it. If you have non-overlapping ranges only, you won’t be affected by this change.

Viewers with the “custom rules” peering policy will be matched against a list of IP ranges and their respective peering configuration (allowed or blocked). This is done by checking all listed ranges in order from top to bottom. Previously, any blocking match would supersede an allowing match, even if the allowing match came first. We’re removing the priority for blocking changes to simplify how matches are determined.

Example for a viewer with private IP address 10.0.0.30:

Scenario 1:
Viewer 1 private IP: 10.0.0.30
Viewer 2 private IP: 11.0.0.30

Custom rules list:

• 10.0.0.0 - 10.0.0.255: allowed
• 11.0.0.0 - 11.0.0.255: blocked
  Fallback policy: blocked

Before:

• Viewer 1 allowed since one allowed match
• Viewer 2 blocked since one blocked match

After:
Same results, no changes in this scenario, since there are no overlapping IP ranges.

Scenario 2:

• Viewer 1 private IP: 10.0.0.30
• Viewer 2 private IP: 11.0.0.30

Custom rules list:

• 10.0.0.0 - 10.0.0.255: allowed
• 10.0.0.0 - 15.0.0.0: blocked
  Fallback policy: blocked

Before:

• Viewer 1 blocked, since one allowed and one blocked match, and blocked matches have higher priority.
• Viewer 2 blocked, since one blocked match.

After:

• Viewer 1 allowed, since the first match encountered (top to bottom) was to allow the IP.
• Viewer 2 blocked, since the only matching rule was blocking the IP.

Scenario 3:
Viewer 1 private IP: 10.0.0.30
Viewer 2 private IP: 11.0.0.30

Custom rules list:

• 10.0.0.0 - 15.0.0.0: blocked
• 10.0.0.0 - 10.0.0.255: allowed
  Fallback policy: blocked

Before:

• Viewer 1 blocked, since one allowed and one blocked match, and blocked matches have higher priority.
• Viewer 2 blocked, since one blocked match.

After:

• Viewer 1 blocked, since the first match encountered (top to bottom) was to block the IP.
• Viewer 2 blocked, since the only matching rule was blocking the IP.
• Please note that smaller IP ranges should be listed before large ranges containing them (top-to-bottom).

Multiple private IP addresses are now supported
Please note that the following change will only materialize if your viewers’ devices have multiple private IP addresses configured on their network interfaces (typically one IPv4 and one IPv6 address).

Previously, eCDN clients would detect their private IP address and always prioritize IPv4 over IPv6. Also, only a single IP address could be detected and sent for matching against custom rules. We’re changing this so that all private IPs configured on the device’s interfaces will be used for matching. To ensure top-to-bottom evaluation, the first rule matching any detected private IP addresses will be used.

Renaming Random peering policy
The policy previously called Random peering policy is now called Testing peering policy. This policy is primarily intended for test purposes and is not designed to provide full performance in production.

Meet Quality Tool improvements
Viewers with the Testing peering policy will now be represented in the Meet Quality Tool eCDN table. Previously this table would only show viewers per configured network if the Custom Rules peering policy was used.

Rollout pace:

• Rapid Release domains: Gradual rollout (up to 15 days for feature visibility) starting on October 6, 2025.
• Scheduled release domains: Gradual rollout (up to 15 days for feature visibility) starting on October 28, 2025.