You are deploying a global external TCP load balancing solution and want to preserve the source IP address of the original layer 3 payload. Which type of load balancer should you use?
Im pretty sure if this was an exam question then the expected answer would be B (NW load balancer)
1) the question says external TCP which is either TCP proxy or Network LB.
2) The question does NOT state anything about LB being regional or global, so there is no harm in choosing Network Load balancer instead of TCP proxy
3) TCP proxy is not a pass through LB, but network LB is. So, Network LB preserves the client IP by default.
NOTE: It is still possible to preserve the client IP via TCP proxy if you use a Proxy Protocol. So, if the question statement was ''External GLOBAL Tcp LB" then i would say the answer is TCP Proxy. But with all we have in the statement, Network LB is a safe answer!
Peace :)
I take that back. Proxy protocol can allow (D) to reserve the original source IP/port https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-protocol
I was wrong, the question indeed says Global. So the answer is D. We cannot preserve the client IPs by default. To do that we need to use a Proxy Protocol.
The question refer to a "global load balancer *solutions*". If you create an NLB in multiple region and pair it with an adequate cloud DNS that is region based this may be considered a global load balancer solution.
You can understand which LB we should use in this situation. The correct answer is "D".
External -> no SSL offload -> Global LB -> TCP Proxy
https://cloud.google.com/load-balancing/docs/choosing-load-balancer#flow_chart
There is one important point to note.
By default, the original(source) client IP address and port information is not preserved. We can preserve this information by using the PROXY protocol.
https://cloud.google.com/load-balancing/docs/tcp#target-proxies
cant be D. TCP/SSL proxy load balancer: While TCP/SSL proxy load balancers can handle TCP and SSL traffic, they do not preserve the original source IP address as they terminate the client connections at the proxy and create new connections to the backend instances.
it's B. it's talking about keeping the ORIGINAL LAYER 3 payload source IP. In the case of TCP/SSL Proxy, when using the PROXY protocol, the payload is NOT preserved. A new connection is established with a new source IP, since the PROXY protocol operates at layer 4, by adding a header with the client IP at the start of TCP connection.
When the IP address of the remote endpoint needs to be preserved, in tandem with TLS connections, there's only solution:
B) passthrough load balancers.
https://cloud.google.com/load-balancing/docs/choosing-load-balancer#proxy-pass-through
https://cloud.google.com/load-balancing/docs/passthrough-network-load-balancer
A) and D) are not correct because the original source address is be lost at TCP connection level (even though it may be somewhere in PROXY information or in some HTTP header), C) is not external.
D. TCP/SSL proxy load balancer
When you use a TCP/SSL proxy load balancer, it preserves the source IP address of the original layer 3 payload. This is because TCP/SSL proxy load balancer terminates the incoming TCP connection and establishes a new one to the backend instance, while retaining the original source IP address in the payload. In contrast, other types of load balancers may modify the source IP address of the payload, making it difficult to track the origin of the request.
• D. TCP/SSL ***** proxy load balancer
Network load balancers are regional in nature and only support backends in the same region as their configured frontends. However, packets to network load balancers can still be sent from anywhere on the internet regardless of whether the IP address of the load balancer is in the Premium Tier or the Standard Tier. If the IP address of the load balancer is in the Premium Tier, the traffic traverses Google's high quality global backbone with the intent that packets enter and exit a Google edge peering point as close as possible to the client. If the IP address of the load balancer is in the Standard Tier, the traffic enters and exits the Google network at a peering point closest to the Google Cloud region where the load balancer is configured.
The correct answer is "D".
External -> no SSL offload -> Global LB -> TCP Proxy
https://cloud.google.com/load-balancing/docs/choosing-load-balancer#flow_chart
By default, the original(source) client IP address and port information is not preserved. We can preserve this information by using the PROXY protocol.
https://cloud.google.com/load-balancing/docs/tcp#target-proxies
https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-protocol
D is right
Set PROXY protocol for retaining client connection information
External TCP Proxy Load Balancing terminates TCP connections from the client and creates new connections to the instances. By default, the original client IP and port information is not preserved.
To preserve and send the original connection information to your instances, enable PROXY protocol (version 1). This protocol sends an additional header that contains the source IP address, destination IP address, and port numbers to the instance as a part of the request.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
seddy
Highly Voted 3 years, 7 months agoEranSolstice
3 years, 2 months agoEranSolstice
3 years, 2 months agoseddy
3 years, 7 months agoEranSolstice
3 years, 2 months agoEranSolstice
3 years, 2 months agoydanno
Highly Voted 3 years, 11 months agonkastanas
Most Recent 5 months, 3 weeks agoNelson90
5 months, 4 weeks agoirmingard_examtopics
9 months agoenter_co
11 months, 1 week agogcpengineer
1 year, 3 months agoBen756
1 year, 9 months agopk349
1 year, 11 months agopfilourenco
2 years agoAzureDP900
2 years, 1 month agoAzureDP900
2 years, 1 month agoMr_MIXER007
2 years, 2 months agoJasonwcc
2 years, 4 months agocsrazdan
2 years, 1 month ago[Removed]
2 years, 10 months ago[Removed]
2 years, 9 months agocoffeecupz
2 years, 11 months agogaggleoxfoggy
2 years, 10 months agokumarp6
2 years, 11 months ago