-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Unexpected behavior when configured with listeners that fail to bind. #3395
Comments
@PiotrSikora are you planning on working on this? |
Not anytime soon. |
@PiotrSikora Do you have plans to fix this? If not, I can handle this. |
@zyfjeff please do, thanks! |
@PiotrSikora, @mattklein123 If this is not being worked on, I can pick it up. I am able to reproduce this issue:
I haven't yet looked closely at why 10001 works and 10002 does not. Right now I'm trying to establish what is the expected behavior. |
I would have to look at this in a bunch of detail to figure out what is going on and what the expected behavior would be. Can you potentially analyze and propose something and then we can discuss? |
Will do. I'll update this issue once I have more substantial information. |
Tested this with two Envoy branches (1.12.2 and master), and found that Envoy appears to be working as expected. That said, there is a behavior difference when testing with containers. When Envoy initializes listeners, the first listener to be created 'wins', so using the provided config:
we end up with:
Testing responses from the same host that is running Envoy, I see that:
If I run envoy in a container and expose both ports 10001 and 10002, from the host machine, only port 10001 works in this configuration since the container interface can respond on port 10001. Since
This makes sense since there is no socket bound on Changing the order of the last pair of listeners 'works' since the first bound socket is the wildcard, which can work through the container interface. I wrote a single threaded binary that mimics the same bind order with the same port and its behavior was identical to what I see with Envoy. If we desire to have this configuration work where we can bind to |
Thanks for the detailed write-up @abaptiste, very nice! From my read of your write-up as well as the original issue, I think @PiotrSikora is probably asking for the config to fail to load in this case in a more obvious way? That would prevent any surprising behavior from ordering issues? @PiotrSikora WDYT? |
I'm working on adding a command line option currently named |
Description:
Envoy successfully starts when configured with listeners on ports that it fails to bind to, which results in unexpected behavior (see below).
Repro steps:
Port
:10001
fail - both connections are matched to the wildcard listener0.0.0.0:10001
, even though more specific listener127.0.0.1:10001
exists (or at least, was configured):Port
:10002
fail - all connections to the wildcard listener0.0.0.0:10002
are refused, because listener127.0.0.1:10002
was configured first:Admin and Stats Output:
Config:
Logs:
The text was updated successfully, but these errors were encountered: