Design, implement, and secure Google Cloud networks, from VPCs and hybrid connectivity to load balancing and Cloud Armor, and track your readiness for the Professional Cloud Network Engineer exam.
Prepare and test your skills
Prepare and test your skills
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.
--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.A VPC spoke supports a maximum of 16 export filters, and configured include ranges must not overlap with each other. In addition, local subnets cannot be larger than the specified filter ranges, and independent address family filtering allows a spoke to export IPv4 or IPv6 prefixes selectively.
Dynamic route propagation follows a strict hierarchy where landing VPC network subnets take first priority, imported hub subnets take second priority, and Cloud Router custom advertised routes take third priority. If a Cloud Router custom route overlaps with an imported hub subnet, the custom route is ignored.
Route tables enforce segmentation across four designated spoke groups: prod, non-prod, services, and gateways. The prod and non-prod groups can each communicate within themselves, with services, and with gateways, but NCC blocks routes directly between prod and non-prod. The services group can communicate with all groups, while the gateways group communicates with prod, non-prod, and services, but cannot communicate with other gateways.
Last updated