Skip to content
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

connection to "localhost" fails with IPv4-only web server if machine has IPv4+IPv6 #613

Open
eric846 opened this issue Jan 28, 2021 · 2 comments
Labels
bug Something isn't working

Comments

@eric846
Copy link
Contributor

eric846 commented Jan 28, 2021

You may get connection failures on some machines.

Sending the load to http://127.0.0.1:12345 does work.

You may have to be using a machine that supports both IPv4 and IPv6

Tentative theory:

  • Because IPv6 is available, Nighthawk resolves localhost to the IPv6 address ::1.
  • The Envoy is explicitly listening only on IPv4 (0.0.0.0) (if I understand correctly).
  • Connecting to ::1 on port 12345 does not reach the Envoy, which is only listening on all IPv4 addresses.

That is, the issue could be with how Nighthawk resolves "localhost" on a dual IPv4/IPv6 machine.

@eric846 eric846 added the bug Something isn't working label Jan 28, 2021
@eric846 eric846 changed the title connection failure with localhost on IPv4 and IPv6 connection to "localhost" fails with IPv4-only web server if machine has IPv4+IPv6 Jan 28, 2021
@oschaaf
Copy link
Member

oschaaf commented Jan 28, 2021

Trace level logging should dig up [1] what address get used to validate, but I think your theory will turn out to be correct.
But ... extending the theory for a bit, if

  • ipv6 gets prioritised over ipv4 at the dns resolution level, and
  • Nighthawk is configured to use either of them ..
    Then one could say the dns resolution behaved as expected?
    If the extended theory holds, then still, I feel this isn't great UX and maybe not that uncommon to run into.
    If we could probe using the other address family upon failure of trying the preferred one and notice that there's a
    L7 service running there, maybe we could write a helpful warning message before exiting.

[1] https://github.com/envoyproxy/nighthawk/blob/main/source/common/uri_impl.cc#L81

@eric846
Copy link
Contributor Author

eric846 commented Feb 11, 2021

Added some advice about localhost, ::1, 127.0.0.1, and --address-family v4 / v6 to the troubleshooting tips in the "error 13" message. This should be enough to unblock most situations.

dubious90 pushed a commit that referenced this issue Apr 1, 2021
When there is a URI exception or failing failure predicate, log troubleshooting tips and return the tips in the Nighthawk Service error description.

Add a default failure predicate for benchmark.stream_resets > 0, since stream resets usually indicate a misconfigured protocol.

NOTE: If you expect stream resets in a benchmark session, run with --failure-predicate benchmark.stream_resets:1000000000 to avoid early termination.

Related to #181 and #613.

Signed-off-by: eric846 <56563761+eric846@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants