-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
Description:
FilterChainMatch has an option source_type that can be (from docs):
ANY - (DEFAULT) Any connection source matches.
LOCAL - Match a connection originating from the same host.
EXTERNAL - Match a connection originating from a different host.
If I set the option to LOCAL I would expect a connection from 100.96.4.33:48158 to 100.96.4.33:9094 to match and be considered local since 100.96.4.33==100.96.4.33. It does not. I have attached the listener config below, I can see in the logs that Envoy is skipping the fc-0 listener filter chain I expect and instead matching the fallthrough fc-1 listener filter chain.
Repro steps:
- Create a listener with a match for
source_type local, such as the following:
{
"version_info": "2019-08-06T18:27:01Z/2",
"listener": {
"name": "100.96.4.33_9094",
"address": {
"socket_address": {
"address": "100.96.4.33",
"port_value": 9094
}
},
"filter_chains": [
{
"filter_chain_match": {
"source_type": "LOCAL"
},
"filters": [
{
"name": "mixer",
...
},
{
"name": "envoy.tcp_proxy",
"config": {
"access_log": [
{
"name": "envoy.file_access_log",
"config": {
"format": "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% \"%DYNAMIC_METADATA(istio.mixer:status)%\" \"%UPSTREAM_TRANSPORT_FAILURE_REASON%\" %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% fc-0\n",
"path": "/dev/stdout"
}
}
],
"stat_prefix": "inbound|9094|server|kafka-svc.kafka.svc.cluster.local",
"cluster": "inbound|9094|server|kafka-svc.kafka.svc.cluster.local"
}
}
]
}
]
...
}
-
If you connect from
100.96.4.33to100.96.4.33:9094through Envoy, expect it to match this listener filter chain and see a log message ending infc-0from theenvoy.file_access_log -
Instead, see it not match this listener filter chain; it may match another depending on your configuration (for me, it matched
fc-1in the detailed full listener dump attached).
kafka-0 istio-proxy [2019-08-06T18:37:03.346Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37796 - fc-1
kafka-0 istio-proxy [2019-08-06T18:37:03.499Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37802 - fc-1
kafka-0 istio-proxy [2019-08-06T18:37:03.837Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37810 - fc-1
kafka-0 istio-proxy [2019-08-06T18:37:04.154Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37816 - fc-1
kafka-0 istio-proxy [2019-08-06T18:37:04.480Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37822 - fc-1
kafka-0 istio-proxy [2019-08-06T18:37:04.794Z] "- - -" 0 - "-" "-" 0 0 0 - "-" "-" "-" "-" "-" - - 100.96.4.33:9094 100.96.4.33:37828 - fc-1
Notes
I am creating the Envoy configuration using an Istio build that I am developing in but I do not believe this is an Istio-specific problem.
I believe I've identified the root cause and I'll open a separate PR with my proposed fix.