Network Connectivity Center (NCC) uses IP and CIDR range filters on its VPC spokes to control which subnet ranges are advertised to the central hub's route table. This precise control prevents overlapping IP address conflicts and enforces network segmentation across hybrid and multi-cloud connections. When connectivity issues arise, troubleshooting involves checking the hub's route table, Cloud Router advertisements, and VPC routing to find routes that were suppressed, dropped, or misconfigured.
Export filters determine the exact IP address ranges a VPC spoke shares with the NCC hub. An administrator can configure a spoke to advertise all its subnets, none of them, or use include and exclude filters for granular control. The --include-export-ranges flag can accept values like ALL_PRIVATE_IPV4_RANGES to advertise all private IPv4 spaces, a specific list of CIDRs, or ALL_IPV6_RANGES. The --exclude-export-ranges flag blocks specific ranges from being advertised, which is useful for keeping subnets private or resolving overlaps. Combining include and exclude filters provides the most precise control, such as advertising all private ranges except for one conflicting subnet.
Hybrid spokes, which connect on-premises networks to NCC via Cloud Interconnect or Cloud VPN, can automatically import subnet ranges from the hub. Enabling the --include-import-ranges flag with ALL_IPV4_RANGES allows the hybrid spoke to receive all IPv4 subnets from the hub's route table and advertise them to its remote BGP peers. The route priority for these imported routes follows a strict order: landing VPC network subnets come first, imported hub subnets second, and any Cloud Router custom advertised routes third. If a custom route overlaps with an imported subnet, the custom route is ignored. Also, if the hybrid spoke's routing VPC uses regional dynamic routing, it only imports hub subnets from the same Google Cloud region.
Common reasons for missing dataplane connectivity include a spoke proposal not being accepted by the hub administrator, all subnets being filtered out, or destination subnets being blocked by filters on the target spoke. If the hub route table is missing some VPC spoke subnets, they might be filtered out or may have been created within the last 5-10 minutes before the hub refreshed. VPC spoke creation can fail due to overlapping subnets with existing spokes, the VPC network already being peered, exceeding quotas, specifying more than 16 export filters, or having subnets larger than the filter ranges.
To verify active filter enforcement, inspect the hub route table to see which subnets are present. Check Cloud Router dynamic route advertisements to see what prefixes are being sent to on-premises peers. Use Cloud Logging to find events related to route suppression, and use Network Topology for a visual map of connections. Connectivity Tests can validate if traffic flows as expected based on the filter rules. For BGP issues, ensure router appliances use RFC 1918 internal IP addresses, not 169.254.x.x addresses, for their BGP sessions.
In inspection topologies using NCC Gateway, segmentation is enforced through four spoke groups: prod, non-prod, services, and gateways. Each group has specific route table rules. The prod group can communicate within itself and with the services and gateway groups, but NCC blocks routes to the non-prod group. The non-prod group has similar rules, blocking access to prod. The services group can talk to any group. The gateways group permits communication with prod, non-prod, and services but not with other gateways. Export filters on VPC spokes control which ranges are exported to their group's route table, and custom BGP advertisements can supplement these automatic routes.
Network Connectivity Center (NCC) IP/CIDR range filters are critical for preventing routing conflicts and enforcing segmentation when multiple connected networks use overlapping IP addresses. These filters act as rules on the BGP sessions between spokes and the hub, governing which prefixes are advertised or accepted. By applying granular filters, administrators ensure deterministic traffic paths and avoid collisions that would break connectivity.
IP/CIDR range filters on NCC spokes are policies that explicitly include or exclude specific IP prefixes from route exchange. To prevent address space overlaps, administrators configure prefix exclusion rules. For example, if two spokes both use the 10.0.0.0/16 range, filters can block its advertisement from each spoke to the hub, preventing other spokes from learning a duplicate route. To enforce route control, specific CIDR matching or aggregation strategies are used. A filter might permit only a summarized prefix (e.g., 10.0.0.0/8) to hide internal details, or permit only specific non-overlapping ranges (e.g., 10.1.1.0/24) to direct traffic to a particular spoke. The choice depends on the design goal: exclusion resolves conflicts directly, specific matching creates precise segmentation, and aggregation simplifies routing but requires careful planning to avoid new overlaps.
Route export and import filters in Network Connectivity Center (NCC) regulate how subnet prefixes propagate between spokes and the hub. These filters enforce segmentation, prevent address conflicts, and help manage route table quotas by ensuring each network only advertises and receives intended IP ranges.
Export filters define which IP ranges a Virtual Private Cloud (VPC) spoke advertises from its local subnets to the NCC hub. Configuration uses include and exclude filter lists. The --include-export-ranges flag permits specific CIDRs, accepting values like ALL_PRIVATE_IPV4_RANGES, ALL_IPV6_RANGES, or a list of blocks. To export privately used public IPv4 ranges, specify ALL_IPV4_RANGES or combine ALL_PRIVATE_IPV4_RANGES with a list of public ranges. The --exclude-export-ranges flag blocks matching subnets from being exported. Design constraints include: include ranges must not overlap with each other, a spoke supports a maximum of 16 export filters, and subnets cannot be larger than the specified filter ranges. Filters also control address families independently, allowing, for example, a spoke to export only IPv6 prefixes.
Import filters on hybrid spokes control how Border Gateway Protocol (BGP) sessions automatically propagate NCC hub subnets to on-premises networks. By default, the --include-import-ranges field is empty, meaning no hub subnets are imported. Setting it to ALL_IPV4_RANGES enables the hybrid spoke to import all IPv4 subnets from the hub route table and advertise them to its remote BGP peers. The hybrid spoke's local routing VPC subnets are always advertised regardless of this setting. Dynamic propagation follows a strict priority: landing VPC network subnets first, imported hub subnets second, and Cloud Router custom routes third. Overlapping custom routes are ignored. Cloud Router policies apply to all imported hub subnets. If the hybrid spoke's routing VPC uses regional dynamic routing, it only imports hub subnets from the same Google Cloud region.
Filters work with spoke group policies to restrict routes in segmented topologies, like inspection architectures with prod, non-prod, services, and gateway groups. VPC spoke export filters apply directly to these group route tables, controlling what each segment learns. Filters also help manage hub scalability by limiting exported ranges to stay within route table quotas. NCC does not check for overlaps with private services access ranges, so administrators must use export filters to prevent conflicts. For troubleshooting, note that a spoke in a different project remains inactive until the hub admin approves it, new subnets take 5-10 minutes to populate the hub, and deleting a VPC spoke triggers a 10-minute cool-down before that VPC can reattach to a different hub.
StudyCerts
StudyCerts--include-export-ranges) and exclude (--exclude-export-ranges) flags to permit or block specific CIDR ranges, with a maximum of 16 filters per VPC spoke.--include-import-ranges parameter to ALL_IPV4_RANGES.Include export filters define a list of CIDR ranges that a VPC spoke is allowed to advertise to the NCC hub. Exclude export filters define a list of ranges that are blocked from being advertised, even if they would otherwise be included. They are often used together for precise control, such as including all private ranges but excluding one specific overlapping subnet.
Enable hub subnet import on a hybrid spoke when you need the spoke to automatically receive all IPv4 subnet routes from the NCC hub's route table and advertise them to your on-premises network via BGP. This is useful for dynamically propagating cloud network changes to your on-premises routers without manual configuration each time a subnet is added or removed.
Filters mitigate overlaps by preventing the advertisement of conflicting IP prefixes. If two spokes use the same 10.0.0.0/16 range, an administrator can configure an exclude export filter on each spoke to block that specific range from being advertised to the hub. This prevents the hub and other spokes from learning duplicate routes, which would cause routing ambiguity and broken connectivity.
A subnet might not appear because it is explicitly blocked by an export filter on that VPC spoke. Alternatively, if the subnet was created very recently (within the last 5-10 minutes), the hub route table may not have refreshed yet. Other causes include the spoke not being active because its proposal hasn't been accepted by the hub administrator.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills