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

Pilot stops pushing routes when tcp:443/https:443 service entries are created #19935

Closed
edude03 opened this issue Jan 6, 2020 · 5 comments · Fixed by #19991
Closed

Pilot stops pushing routes when tcp:443/https:443 service entries are created #19935

edude03 opened this issue Jan 6, 2020 · 5 comments · Fixed by #19991

Comments

@edude03
Copy link

@edude03 edude03 commented Jan 6, 2020

Bug description
If you create two wildcard ServiceEntries for port 443 with https/tcps protocol likes so

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
spec:
  hosts:
  - '*.site-a.com'
  ports:
  - name: https
    number: 443
    protocol: HTTPS
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
spec:
  hosts:
  - '*.site-b.com'
  ports:
  - name: tcp
    number: 443
    protocol: TCP

Internal:Error adding/updating listener(s) 0.0.0.0_443: error adding listener '0.0.0.0:443': multiple filter chains with the same matching rules are defined

and the LDS status to be stale for all proxies



**Expected behavior**

**Steps to reproduce the bug**

**Version (include the output of `istioctl version --remote` and `kubectl version` and `helm version` if you used Helm)**

Istio 1.4.1

**How was Istio installed?**

Helm template

**Environment where bug was observed (cloud vendor, OS, etc)**
GKE Kubernetes 1.14
@hzxuzhonghu

This comment has been minimized.

Copy link
Member

@hzxuzhonghu hzxuzhonghu commented Jan 6, 2020

could you show the result of istioctl pc listener xxx --port=443 --address=0.0.0.0 -ojson?

@edude03

This comment has been minimized.

Copy link
Author

@edude03 edude03 commented Jan 7, 2020

@hzxuzhonghu I can't run that since I've fixed it now by removing site-b from my rules, but have a look at https://gist.github.com/edude03/a4ec5e0b651e0bbbad92d07c962ef8f8

@hzxuzhonghu

This comment has been minimized.

Copy link
Member

@hzxuzhonghu hzxuzhonghu commented Jan 7, 2020

site-b will generate a listener filterchain with filterchainmatch = {}, but we have removed duplication by this.

if fc.FilterChainMatch == nil || reflect.DeepEqual(fc.FilterChainMatch, wildcardMatch) {

So I think still need more info to get the root cause

@edude03

This comment has been minimized.

Copy link
Author

@edude03 edude03 commented Jan 7, 2020

I spoke to @howardjohn on slack about this and he said

basically we have that one has a null match, and another one has a {} which we treat different but envoy doesnt

Link to the thread

but if there is more information I can provide let me know :)

@hzxuzhonghu

This comment has been minimized.

Copy link
Member

@hzxuzhonghu hzxuzhonghu commented Jan 7, 2020

But i can not reproduce with the above config

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can’t perform that action at this time.