Matching IP Family for Outbound Listener #16804
Description
Title: Matching IP Family for Outbound Listener
Description:
To support dual stack in istio, for each service that has dual stack configured, two outbound listeners for the same port are created. One listener is with ipv6 wildcard with port and the other one is with ipv4 wildcard with port.
Here is what we expect:
client (ipv4 address ) -> ipv4 iptable redirect to 15001 -> envoy original dst at 15001 -> only match ipv4 wildcard 0.0.0.0: listener
client (ipv6 address ) -> ipv6 iptable redirect to 15001 -> envoy original dst at 15001 -> only match ipv6 wildcard [::]: listener
However, in the connection_handler_impl.cc
it was not matching IP family type for the listener and target address. Instead, it finds the first wildcard matching port from the listener list and it always returns that listener. This causes downstream client can use a different IP family listener from the original destination address. We think the code should match IP family and pick the corresponding wildcard listener based on the original destination IP family type.
ConnectionHandlerImpl::findActiveTcpListenerByAddress(const Network::Address::In
p.second.typed_listener_) &&
p.second.listener_->listener() != nullptr &&
p.first->type() == Network::Address::Type::Ip &&
- p.first->ip()->port() == address.ip()->port() && p.first->ip()->isAnyAddress();
+ p.first->ip()->port() == address.ip()->port() && p.first->ip()->isAnyAddress() &&
+ ((p.first->ip()->ipv4() != nullptr && address.ip()->ipv4() != nullptr) ||
+ (p.first->ip()->ipv6() != nullptr && address.ip()->ipv6() != nullptr));
});
With the above change, we tested with success of either IPv4 or IPv6 path.
kubectl exec -it -n test sleep-86786f67f4-s5bfm sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Defaulted container "sleep" out of: sleep, istio-proxy, istio-init (init)
/ # curl 10.96.65.101:8090/headers
X-Request-Id: a6b06ffb-724b-4785-b490-039dbde0baee
X-B3-Spanid: c1d76544d090db82
Accept: */*
X-Envoy-Attempt-Count: 1
Content-Length: 0
X-Forwarded-Client-Cert: By=spiffe://cluster.local/ns/test/sa/simpleserver;Hash=01b9728bd23645e1afc39c96826cbec8b46c6427ac9b147b998935cdd2271adc;Subject="";URI=spiffe://cluster.local/ns/test/sa/sleep
X-B3-Traceid: 24c6d5522b6172d88f843df561d424d8
X-B3-Parentspanid: 8f843df561d424d8
X-B3-Sampled: 0
User-Agent: curl/7.76.1
X-Forwarded-Proto: http
remote addr: 127.0.0.1:48372
host addr: 10.96.65.101:8090
/ # curl simpleserver:8090/headers
X-Forwarded-Client-Cert: By=spiffe://cluster.local/ns/test/sa/simpleserver;Hash=01b9728bd23645e1afc39c96826cbec8b46c6427ac9b147b998935cdd2271adc;Subject="";URI=spiffe://cluster.local/ns/test/sa/sleep
X-B3-Spanid: ea96060aa7025f33
X-B3-Parentspanid: f5e7ec00645e238a
User-Agent: curl/7.76.1
Accept: */*
X-Forwarded-Proto: http
X-Request-Id: f6e2dcb1-664d-4f54-baa1-0d5ca615a562
X-Envoy-Attempt-Count: 1
Content-Length: 0
X-B3-Traceid: 872552dfa9f3c99bf5e7ec00645e238a
X-B3-Sampled: 0
remote addr: [::1]:58248
host addr: simpleserver:8090
ipv6 only server
This is important for us to enable dual mode support in Istio as we create routes/clusters based on whether IPv4 or IPv6 listener is picked.
Repro steps:
Include sample requests, environment, etc. All data and inputs
required to reproduce the bug.
Note: The Envoy_collect tool
gathers a tarball with debug logs, config and the following admin
endpoints: /stats, /clusters and /server_info. Please note if there are
privacy concerns, sanitize the data prior to sharing the tarball/pasting.
Attached the config_dump from istio.
Admin and Stats Output:
Include the admin output for the following endpoints: /stats,
/clusters, /routes, /server_info. For more information, refer to the
admin endpoint documentation.
Config:
Include the config used to configure Envoy.
Logs:
Envoy logs with added trace: