This allows users to specify literal socket options that may not be compatible with upstream kernels or available in precompiled Envoy binaries.
Risk Level: Low
Testing:
Existing tests pass plus new test to cover new functionality.
Partial fix for #3661.
Signed-off-by: Trevor Schroeder <trevors@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 20c0454545761c254180f77948304083406757be
This follows up from #558 which made IP_FREEBIND a BoolValue for LDS but
not for upstream. I think it makes sense to have it in both places given
the new socket options setup introduce in
https://github.com/envoyproxy/envoy/pull/2734.
Some bonus docs fixups thrown in.
Signed-off-by: Harvey Tuch <htuch@google.com>
Document the behavior when each option is set to true, set to false,
or unset.
Document that the transparent option should be used in conjunction
the original_dst_filter to restore the original destination address.
Signed-off-by: Romain Lenglet <romain@covalent.io>
Add an option "freebind" in LDS for listeners and the BindConfig which
is used for outgoing upstream connections. If true, set IP_FREEBIND
socket option. Defaults to false.
PR description will be updated with Envoy implementation PR# once it is
created.
Signed-off-by: Dan Noé <dpn@google.com>
Add a "transparent" option to Listener to set the SOL_IP/IP_TRANSPARENT option on listen sockets, which allows using Envoy with the iptables TPROXY target.
Unlike the iptables REDIRECT target, TPROXY allows preserving both the source and destination IP addresses and ports of accepted connections.
API changes for: envoyproxy/envoy#2719
Signed-off-by: Romain Lenglet <romain@covalent.io>
This enables generating generic service stubs for all the data-plane-api
proto services when generating Java classes with protoc.
This is generally not needed when implementing a gRPC server but in our case we're implementing
it behind our legacy protobuf RPC framework which rely on these stubs. As far as I know the only negative
with enabling these is generating some potentially unnecessary Java classes.
Signed-off-by: Snow Pettersen <snowp@squareup.com>
I went through and reorganized things to make the v2 docs more
human browsable. I also did a few misc cleanups. There is a lot
more to do here which I'm hoping to find a contractor to pay to
work on, but this is a step in the right direction.
Signed-off-by: Matt Klein <mklein@lyft.com>
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@google.com>