You are migrating your on-premises solution to Google Cloud in several phases. You will use Cloud VPN to maintain a connection between your on-premises systems and Google Cloud until the migration is completed. You want to make sure all your on-premise systems remain reachable during this period. How should you organize your networking in Google Cloud?
To maintain connectivity between your on-premises systems and Google Cloud during a phased migration using Cloud VPN, it is crucial to avoid IP address conflicts. The correct approach is to use an IP range on Google Cloud that does not overlap with the range used on-premises. This ensures that traffic can be routed smoothly between the two environments, preventing any address duplication or routing issues.
Ans is C, https://cloud.google.com/vpc/docs/using-vpc "Primary and secondary ranges can't conflict with on-premises IP ranges if you have connected your VPC network to another network with Cloud VPN, Dedicated Interconnect, or Partner Interconnect."
Agreed!
Perfect.. Exact find in link.
from the above link - it clearly states - "Primary and secondary ranges for subnets cannot overlap with any allocated range, any primary or secondary range of another subnet in the same network, or any IP ranges of subnets in peered networks." once we create a VPN, they all are part of the same network . Hence option C is correct
agree, any ip range, shall use filewall rule to communicate, instead of setting same IP range, which is a mess to control.
I think C is correct.
Agree with C. Secondary IP range still can't overlap
".... and Google Cloud until the migration is completed." Taking this as the key, the intention is to remove the connection b/w on-prem and GCP once the migration is done. and then the secondary IPs will act as primary. So I will choose D
C is ok
B, The key points here: - migrating in several phases - use Cloud VPN until the migration is completed - all your on-premise systems remain reachable during this period
how to manage the routing table in VPC if is present a subnet with the same network of vpn remote net? the correct answer is C
Yes C it is
C, no brainer. You have on-prem <--> VPN <---> GCP only way this data flow to work in non-over lapping subnets. You can stretch subnets at layer 7 but you wont be able to route it via VPN.
I got similar question on my exam.
Using an IP range on Google Cloud that does not overlap with the range used on-premises (option C) is a good choice to avoid IP address conflicts. However, it is important to use the same IP range as the on-premises applications for the primary IP range to ensure that the on-premises systems remain accessible. Therefore, using the same IP range on Google Cloud as on-premises for the primary IP range and using a secondary range that does not overlap with the range used on-premises can avoid IP address duplication and ensure that the on-premises systems remain accessible. Hence, option B is the better choice.
Is D corecct?! Really? I agree with C is correct.
ANS - C Primary and secondary ranges for subnets cannot overlap with any allocated range, any primary or secondary range of another subnet in the same network, or any IPv4 ranges of subnets in peered networks.
The correct answer is C
The recommended approach for organizing your networking in Google Cloud to ensure that all your on-premises systems remain reachable during the migration is option C: Use an IP range on Google Cloud that does not overlap with the range you use on-premises. When using Cloud VPN to establish a connection between your on-premises systems and Google Cloud, it is important to ensure that the IP ranges used in your on-premises systems and Google Cloud do not overlap. If the IP ranges overlap, it can cause conflicts and make it difficult to route traffic between your on-premises systems and Google Cloud. To avoid IP range conflicts, you should use an IP range on Google Cloud that is different from the range you use on-premises. This will ensure that all your on-premises systems remain reachable during the migration.
Option A: Using the same IP range on Google Cloud as you use on-premises is not a recommended approach, as it can cause IP range conflicts and make it difficult to route traffic between your on-premises systems and Google Cloud. Option B: Using the same IP range on Google Cloud as you use on-premises for your primary IP range and a secondary range that does not overlap with the range you use on-premises is not a recommended approach, as it can still cause IP range conflicts and make it difficult to route traffic between your on-premises systems and Google Cloud. Option D: Using an IP range on Google Cloud that does not overlap with the range you use on-premises for your primary
From here: https://cloud.google.com/vpc/docs/create-modify-vpc-networks "Primary and secondary ranges can't conflict with on-premises IP ranges if you have connected your VPC network to another network with Cloud VPN, Dedicated Interconnect, or Partner Interconnect."
Answer is C
C Why would you ever create an IP overlap?
C, IP should never overlap if avoidable. double nat is nasty
C. Use an IP range on Google Cloud that does not overlap with the range you use on-premises
no overlapping
ok for C
C is correct
question is tricky. as network architect knowing gcp i have exp that you can use non-overlapping secondary ranges for vpn as well. in many migrations it is not possible to make new addressing hence you need to make them overlapping. this is why 2nd ranges are so useful. B is better choice. more realistic and possible in gcp. from overall perspective i agree to have non-overlapping but do not forget this is migration and you need to have full connectivity all the time. it is also not mentioning about what ips should be used