By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Network Load Balancer

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Unexpected URI while testing API gateway to NLB

I have a Private Link setup that points at an NLB that further has routes setup to an EC2 instance that provides my HTTP end point. I am trying to setup an API gateway to use the private link. I tried setting this up as proxy. This allows me to test an endpoint without authorization, and provide both path and query parameters. This is the log of the output I am seeing. ``` Execution log for request e114f111-f6b5-413d-9592-ec1ecb72d848 Mon Mar 07 19:38:02 UTC 2022 : Starting execution for request: e114f111-f6b5-413d-9592-ec1ecb72d848 Mon Mar 07 19:38:02 UTC 2022 : HTTP Method: GET, Resource Path: /api/falcfunnelsession/getInvestorResponse Mon Mar 07 19:38:02 UTC 2022 : Method request path: {proxy=api/falcfunnelsession/getInvestorResponse} Mon Mar 07 19:38:02 UTC 2022 : Method request query string: {sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c} Mon Mar 07 19:38:02 UTC 2022 : Method request headers: {} Mon Mar 07 19:38:02 UTC 2022 : Method request body before transformations: Mon Mar 07 19:38:02 UTC 2022 : Endpoint request URI: https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c Mon Mar 07 19:38:02 UTC 2022 : Endpoint request headers: {x-amzn-apigateway-api-id=8v1qbgdlb8, User-Agent=AmazonAPIGateway_8v1qbgdlb8, Host=funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com} Mon Mar 07 19:38:02 UTC 2022 : Endpoint request body after transformations: Mon Mar 07 19:38:02 UTC 2022 : Sending request to https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c Mon Mar 07 19:38:07 UTC 2022 : Execution failed due to configuration error: There was an internal error while executing your request Mon Mar 07 19:38:07 UTC 2022 : Method completed with status: 500 ``` The following path and query are as expected ``` Mon Mar 07 19:38:02 UTC 2022 : HTTP Method: GET, Resource Path: /api/falcfunnelsession/getInvestorResponse Mon Mar 07 19:38:02 UTC 2022 : Method request path: {proxy=api/falcfunnelsession/getInvestorResponse} Mon Mar 07 19:38:02 UTC 2022 : Method request query string: {sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c} ``` However the URI request seems to leave out the path. ``` Mon Mar 07 19:38:02 UTC 2022 : Endpoint request URI: https://funnel-backend-103-nlb-bc34d52397cf6529.elb.us-east-2.amazonaws.com?sessionUUID=7a0e0113-05ab-4382-bed8-f91e9bc3ef3c ``` Wondering is there is something I am doing wrong here. thanks!
2
answers
0
votes
427
views
asked 7 months ago

Network Load Balancer stickiness seems to fail sometimes

We have a SignalR javascript client connecting to .net core hub, hosted in AWS. Both client and server use version 6. More than one backend server may exist, so there is an internet facing Network Load Balancer forwarding the traffic to the backend servers. The NLB is configured with these options: - Stickiness - Preserve client IP addresses Most of the time, everything works great: the negotiation and the connection upgrade. Sometimes, however, something strange happens: the negotiation fails (error in WebSocket transport), then the client tries again with another transport (SSE). This transport also fails and, while retrying, the client hits the other host, starting the negotiation again. Finally, the connection succeeds. All this process takes no more than 5 seconds. This was happening in our clients, from outside, so we set up an isolated environment to debug this situation, with the NLB and 2 backend hosts. This is internal, so no one else is connecting, for sure, so there is no chance hosts are overloaded. We are completely sure our IP does not change while the test is being done. We enabled client and server debug logs, shown below. This still happens sometimes, no matter the host that we hit on the first attempt. We know that we can configure the client to skip the negotiation, but that will make us lose about 10% of our clients, because we will be limited to use the WebSockets transport. From the logs, IP stickiness seems to be failing somehow... What is misconfigured in our setup? How can the negotiation fail if just one client is connecting and the IP does not change? What else can we configure in the AWS NLB to ensure the IP stickiness? Thanks in advance! **When the connection succeeds at the first attempt** ``` Client logs Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. Information: WebSocket connected to wss://<server>... Debug: The HttpConnection connected successfully. Server logs [DBG] New connection r3Gv5PrBgTA2T6lijqwTrA created. [DBG] Sending negotiation response. [DBG] Establishing new connection. [DBG] Socket opened using Sub-Protocol: 'null'. [DBG] OnConnectedAsync started. [DBG] Found protocol implementation for requested protocol: json. [DBG] Completed connection handshake. Using HubProtocol 'json'. ``` **When the connection fails at the first attempt** ``` Client logs Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. WebSocket connection to 'wss://<server>...' failed: Information: (WebSockets transport) There was an error with the transport. Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled. Debug: Selecting transport 'ServerSentEvents'. Debug: Sending negotiation request: https://<server>... Trace: (SSE transport) Connecting. Information: SSE connected to https://<server>... Debug: The HttpConnection connected successfully. Trace: (SSE transport) sending data. String data of length 32. POST https://<server>... 404 (Not Found) Debug: HttpConnection.stopConnection(undefined) called while in state Disconnecting. Error: Connection disconnected with error 'Error: No Connection with that ID: Status code '404''. Debug: Starting connection with transfer format 'Text'. Debug: Sending negotiation request: https://<server>... Debug: Selecting transport 'WebSockets'. Trace: (WebSockets transport) Connecting. Information: WebSocket connected to wss://<server>... Debug: The HttpConnection connected successfully. Server logs (server 1) [DBG] New connection _cm5IaOtqY7tD7suKOb08Q created. [DBG] Sending negotiation response. (1) [DBG] New connection GuXhVydEzL-8xXcSxibysA created. [DBG] Sending negotiation response. (2) [DBG] Establishing new connection. [DBG] OnConnectedAsync started. [DBG] Failed connection handshake. (server 2) [DBG] New connection RjoZW-BKBNMOa2UBW9yo-g created. [DBG] Sending negotiation response. [DBG] Establishing new connection. [DBG] Socket opened using Sub-Protocol: 'null'. [DBG] OnConnectedAsync started. [DBG] Found protocol implementation for requested protocol: json. [DBG] Completed connection handshake. Using HubProtocol 'json'. ```
1
answers
0
votes
520
views
asked 7 months ago