-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example app udp-greeter.yaml not working - help needed #133
Comments
Can you please provide more info? We'd need at least the output from |
Hi @rg0now, Thanks for reply. Attached some information you requested. i don't see any stunnerd pods running... |
I can't see any apparent problem with your setup. Can you please elevate the loglevel on the gateway so that we see why the connection hangs and rerun the test? Here is a simple way to set the maximum loglevel:
|
i updated the log level in stunner-gatewayconfig to trace and stunner-gateway-operator-controller-manager to debug before getting this logs... please check if helps one thing i noticed is that LoadBalancer (Network LB) service exposes only UDP . should it expose TCP as well?. If so, how to do that.. |
Unfortunately I'm no expert in AWS load-balancers, but you may be on the right track here: last time we looked at it AWS required a TCP health-checker to accept a UDP LoadBalancer. Can you experiment with the following annotations added to the Gateway?
What is strange is that the stunner-udp-gateway-log.txt actually shows a successful authentication attempt from someone (please check the source IP: is that one of your pods or it's coming from the outside?). Can you resend the stunner-udp-gateway-log.txt, but this time with the elevated loglevel? |
I am also seeing this problem:
|
Just to make it clear: after elevating the
This is because we need to see whether the connection request from
We need to see what happened afterwards in the dataplane. Frankly, the whole thing is quite mysterious: if the authentication request were not successful then we would see that clearly in the logs, but if it was (like in our case), then why the client did not continue with establishing the connection? That's what the trace level logs would reveal (I hope). One minor silly thing: after running |
Does turncat automatically add in credentials from the deployment, or do we have to add them in the udp connection string? |
Theoretically, it should. It actually asks the operator for the running config of the gateway corresponding to the |
Closing this for now, feel free to reopen of anything new comes up. |
Hi,
I am tying to setup the example to make sure this solution can be used for my scenario and looks like all the pods/services are running fine. But when i test the example to make sure everything works fine, getting below error... I am running this example on AWS EKS cluster. any ideas what could be wrong??
The text was updated successfully, but these errors were encountered: