DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7 #89520

duylong · 2020-03-26T13:28:27Z

Hi,

Since my upgrade to 1.18 version, I have errors in kube-proxy:

E0326 13:14:23.847364       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847388       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:53/UDP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847479       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847501       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:53/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847595       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847617       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:9153/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847706       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 7]
E0326 13:14:23.847728       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::7964]:443/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 7]
E0326 13:14:23.847813       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 41]
E0326 13:14:23.847835       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::dc23]:80/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 41]
E0326 13:14:23.848063       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 221 172 173 0 21 1 42 2 80 86 255 254 177 6 5]
E0326 13:14:23.848085       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::1]:443/TCP, err: parseIP Error ip=[253 221 172 173 0 21 1 42 2 80 86 255 254 177 6 5]
...

I have ipv4/ipv6 dualstack enable. No problem with cluster and IPVS works despite errors.

Do you have also this issue ?

OS: RHEL7
Kubernetes version (use kubectl version):

Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}```

The text was updated successfully, but these errors were encountered:

neolit123 · 2020-03-26T18:00:57Z

/sig network

liggitt · 2020-03-27T01:07:58Z

Related to https://github.com/kubernetes/kubernetes/pull/89343/files#diff-71a24186bd4c7e94c34819c55dfa89af?

cc @aojea @thockin

SataQiu · 2020-03-27T06:46:18Z

/cc

aojea · 2020-03-27T07:18:59Z

Taking one of the outputs it gives me the following addresses?
https://play.golang.org/p/K196eO64r5v

Address: fd00:10:245:0:c0bb:b693:aecf:6707, [253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 7]
Address: fd00:10:96::a [253 0 0 16 0 150 0 0 0 0 0 0 0 0 0 10]

@duylong can you share more details about your environment,

Is it possible that the CoreDNS pod has the address fd00:10:245:0:c0bb:b693:aecf:6707?
what are your cluster-cidr and service-cidr?

Indeed that new net.Utils change looks suspicious , a quick grep in the repo gives me some suspects, maybe the service/ipallocator?

$ grep -r GetIndexedIP *
cmd/kubeadm/app/util/apiclient/init_dryrun.go:  internalAPIServerVirtualIP, err := utilnet.GetIndexedIP(svcSubnet, 1)
cmd/kubeadm/app/constants/constants.go: dnsIP, err := utilnet.GetIndexedIP(svcSubnetCIDR, 10)
cmd/kubeadm/app/constants/constants.go: internalAPIServerVirtualIP, err := utilnet.GetIndexedIP(svcSubnet, 1)
cmd/kubeadm/app/preflight/checks.go:    testIP, err := utilsnet.GetIndexedIP(cidr, 1)
pkg/master/services.go: apiServerServiceIP, err := utilnet.GetIndexedIP(&serviceClusterIPRange, 1)
pkg/registry/core/service/ipallocator/allocator.go:             ip, _ := utilnet.GetIndexedIP(r.net, offset+1) // +1 because Range doesn't store IP 0

It's important to mention there were similar issues with IPVS before, interpreting IPv4 addresses as IPv6, @uablrek has some experience with this kind of issues, maybe he can see something:)

#87604
#65006

/cc

uablrek · 2020-03-27T08:11:08Z

A bit tricky to trace since libnetwork/ipvs is moving around at the moment. Problem seems to be in;
https://github.com/moby/ipvs/blob/8f137da6850a975020f4f739c589d293dd3a9d7b/netlink.go#L260-L274

The "family" must be wrong. It is called from;
https://github.com/moby/ipvs/blob/8f137da6850a975020f4f739c589d293dd3a9d7b/netlink.go#L463

uablrek · 2020-03-27T08:16:49Z

@duylong Please do a ipvsadm -Ln and attach the output.

duylong · 2020-03-27T08:27:07Z

Hi,

Some informations:

default       kubernetes                   [fddd:acad:15:12a:250:56ff:feb1:605]:6443                                                                                           42d
kube-system   kube-dns                     [fd00:10:245:0:c0bb:b693:aecf:6727]:53,[fd00:10:245:0:dde8:fb36:cc62:37c]:53,[fd00:10:245:0:c0bb:b693:aecf:6727]:9153 + 3 more...   42d
kube-system   metrics-server               [fd00:10:245:0:c0bb:b693:aecf:6707]:4443

cluster-cidr and service-cidr:

fd00:10:245:0:0:0:0:0/64,10.245.0.0/16
fd00:10:96:0:0:0:0:0/112,10.96.0.0/12

ipvsadm output:

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  [fd00:10:96::1]:443 lc
  -> [fddd:acad:15:12a:250:56ff:feb1:605]:6443 Masq    1      1          0
TCP  [fd00:10:96::a]:53 lc
  -> [fd00:10:245:0:c0bb:b693:aecf:6727]:53 Masq    1      0          0
  -> [fd00:10:245:0:dde8:fb36:cc62:37c]:53 Masq    1      0          0
TCP  [fd00:10:96::a]:9153 lc
  -> [fd00:10:245:0:c0bb:b693:aecf:6727]:9153 Masq    1      0          0
  -> [fd00:10:245:0:dde8:fb36:cc62:37c]:9153 Masq    1      0          0
TCP  [fd00:10:96::7964]:443 lc
  -> [fd00:10:245:0:c0bb:b693:aecf:6707]:4443 Masq    1      2          0
UDP  [fd00:10:96::a]:53 lc
  -> [fd00:10:245:0:c0bb:b693:aecf:6727]:53 Masq    1      0          0
  -> [fd00:10:245:0:dde8:fb36:cc62:37c]:53 Masq    1      0          0
TCP  [fd00:10:96::dc23]:80 lc
  -> [fd00:10:245:0:c0bb:b693:aecf:6729]:80 Masq    1      0          0
....

SataQiu · 2020-03-27T13:45:02Z

Ref: 8d7780d

uablrek · 2020-03-27T13:54:41Z

@SataQiu The commit in the ref above should be in v1.18.0 which is the version used in this issue. So the commit does not fix the problem.

SataQiu · 2020-03-27T15:17:48Z

@uablrek Maybe something wrong around here https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/docker/libnetwork/ipvs/netlink.go#L463
Before this commit, it looks like this:

ip, err := parseIP(attr.Value, syscall.AF_INET)

Now it looks like this:

ip, err := parseIP(attr.Value, d.AddressFamily)

However d.AddressFamily is not initialized，it is zero :(.

uablrek · 2020-03-27T18:23:04Z

I do not get these faults. Has the netlink API changed?

@duylong What kernel version are you using?

uablrek · 2020-03-27T19:05:50Z

d.AddressFamily is supposed to be set from the "NetlinkRouteAttr" slice;

kubernetes/vendor/github.com/docker/libnetwork/ipvs/netlink.go

Line 435 in 3842a92

d.AddressFamily = native.Uint16(attr.Value)

It should definitely not be hard-coded to ipv4.

rikatz · 2020-03-27T21:39:38Z

Made a gist trying to reproduce this in my environment but didn't got this error. I may try this on some older kernel like from CentOS 7

Added exactly the same IPVS configuration here:

ipvsadm -A -t [fd00:10:96::1]:443 -s lc
ipvsadm -a -t [fd00:10:96::1]:443 -r [fddd:acad:15:12a:250:56ff:feb1:605]:6443 -m
ipvsadm -L -n
ipvsadm -A -t [fd00:10:96::a]:53 -s lc
ipvsadm -L -n
ipvsadm -a -t [fd00:10:96::a]:53 -r [fd00:10:245:0:c0bb:b693:aecf:6727]:53
ipvsadm -a -t [fd00:10:96::a]:53 -r [fd00:10:245:0:dde8:fb36:cc62:37c]:53
ipvsadm -A -u [fd00:10:96::a]:53 -s lc
ipvsadm -a -u [fd00:10:96::a]:53 -r [fd00:10:245:0:dde8:fb36:cc62:37c]:53
ipvsadm -a -u [fd00:10:96::a]:53 -r [fd00:10:245:0:c0bb:b693:aecf:6727]:53

And when running this 'gist/program' pointing to the IPVS from the DNS (fd00:10:96::a port 53 UDP) got the expected result:

&{fd00:10:245:0:c0bb:b693:aecf:6727 53 1 0 0}&{fd00:10:245:0:dde8:fb36:cc62:37c 53 1 0 0}

Maybe trying to run this also in some other scenarios could clarify if this is something related to Netlink API changed between Kernels, something with the used library, etc.

SataQiu · 2020-03-28T07:22:55Z

After some study, I find that this issue most likely is caused by the low linux kernel version.
I have reproduced this problem on Linux CentOS 3.10.0-693.el7.x86_64.

Accroding to the code, netlink will try to get d.AddressFamily attribute, but I find the kernel just does not support it :(

This is the Destination Attributes defined in /usr/include/linux/ip_vs.h (kernel 3.10)

/*
 * Attributes used to describe a destination (real server)
 *
 * Used inside nested attribute IPVS_CMD_ATTR_DEST
 */
enum {
	IPVS_DEST_ATTR_UNSPEC = 0,
	IPVS_DEST_ATTR_ADDR,		/* real server address */
	IPVS_DEST_ATTR_PORT,		/* real server port */

	IPVS_DEST_ATTR_FWD_METHOD,	/* forwarding method */
	IPVS_DEST_ATTR_WEIGHT,		/* destination weight */

	IPVS_DEST_ATTR_U_THRESH,	/* upper threshold */
	IPVS_DEST_ATTR_L_THRESH,	/* lower threshold */

	IPVS_DEST_ATTR_ACTIVE_CONNS,	/* active connections */
	IPVS_DEST_ATTR_INACT_CONNS,	/* inactive connections */
	IPVS_DEST_ATTR_PERSIST_CONNS,	/* persistent connections */

	IPVS_DEST_ATTR_STATS,		/* nested attribute for dest stats */
	__IPVS_DEST_ATTR_MAX,
};

No IPVS_DEST_ATTR_ADDR_FAMILY attribute is defined!

But in new kernel version, the Destination Attributes is defined like this:

/*
 * Attributes used to describe a destination (real server)
 *
 * Used inside nested attribute IPVS_CMD_ATTR_DEST
 */
enum {
	IPVS_DEST_ATTR_UNSPEC = 0,
	IPVS_DEST_ATTR_ADDR,		/* real server address */
	IPVS_DEST_ATTR_PORT,		/* real server port */

	IPVS_DEST_ATTR_FWD_METHOD,	/* forwarding method */
	IPVS_DEST_ATTR_WEIGHT,		/* destination weight */

	IPVS_DEST_ATTR_U_THRESH,	/* upper threshold */
	IPVS_DEST_ATTR_L_THRESH,	/* lower threshold */

	IPVS_DEST_ATTR_ACTIVE_CONNS,	/* active connections */
	IPVS_DEST_ATTR_INACT_CONNS,	/* inactive connections */
	IPVS_DEST_ATTR_PERSIST_CONNS,	/* persistent connections */

	IPVS_DEST_ATTR_STATS,		/* nested attribute for dest stats */

	IPVS_DEST_ATTR_ADDR_FAMILY,	/* Address family of address */

	IPVS_DEST_ATTR_STATS64,		/* nested attribute for dest stats */

	IPVS_DEST_ATTR_TUN_TYPE,	/* tunnel type */

	IPVS_DEST_ATTR_TUN_PORT,	/* tunnel port */

	IPVS_DEST_ATTR_TUN_FLAGS,	/* tunnel flags */

	__IPVS_DEST_ATTR_MAX,
};

Obviously, the kernel has added some attributes (IPVS_DEST_ATTR_ADDR_FAMILY, IPVS_DEST_ATTR_STATS64...).

That is why kube-proxy works well on systems with a higher version of the kernel.

So we can address this issue by upgrading our linux kernel.
Not sure which kernel version is the minimum requirement, maybe we should document something about this.

SataQiu · 2020-03-28T07:29:42Z

Here is the Destination Attributes defined in docker/libnetwork:
https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/docker/libnetwork/ipvs/constants.go#L76-L89

// Attributes used to describe a destination (real server). Used
// inside nested attribute ipvsCmdAttrDest.
const (
	ipvsDestAttrUnspec int = iota
	ipvsDestAttrAddress
	ipvsDestAttrPort
	ipvsDestAttrForwardingMethod
	ipvsDestAttrWeight
	ipvsDestAttrUpperThreshold
	ipvsDestAttrLowerThreshold
	ipvsDestAttrActiveConnections
	ipvsDestAttrInactiveConnections
	ipvsDestAttrPersistentConnections
	ipvsDestAttrStats
	ipvsDestAttrAddressFamily
)

uablrek · 2020-03-30T05:41:49Z

@SataQiu Good finding.

So, we can conclude that this really is kernel version dependent. It is hard to know what to do about it. We must check the family. I would propose that we make it work for ipv4 with some fallback and put a requirement on kernel version for ipv6-only/dual-stack. But the decision is others to make.

/cc @andrewsykim @thockin

uablrek · 2020-03-30T05:46:38Z

/cc @m1093782566

uablrek · 2020-03-30T06:04:40Z

The symbol in the kernel tree https://github.com/torvalds/linux/blob/7111951b8d4973bda27ff663f2cf18b663d15b48/include/uapi/linux/ip_vs.h#L404

The IPVS_SVC_ATTR_AF for service family https://github.com/torvalds/linux/blob/7111951b8d4973bda27ff663f2cf18b663d15b48/include/uapi/linux/ip_vs.h#L360 seems very old. Since the service must have the same family as the real-servers perhaps it can be used for compatibility with old kernels?

uablrek · 2020-03-30T06:07:34Z

The commit that adds the symbol;torvalds/linux@6cff339
Seem to go into linux-3.18

duylong · 2020-03-30T07:48:53Z

I did not know the minimum required for the kernel version, I was using the stable and official version of RHEL7.

My kernel version is:

Linux XXX 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux

Currently the max version in the repository is:

3.10.0-1062.18.1.el7.x86_64

According to the documentation (https://access.redhat.com/articles/3078), I should switch to RHEL8 if I want a recent kernel :-\

uablrek · 2020-03-30T07:54:03Z

There is no minimum kernel version requirement afaik. So I think this must be fixed for ipv4-only clusters IMO. However ipv6-only and dual-stack are in "alpha" so a requirement on kernel version might be ok, but I can't say myself.
A complication is that the problem is not in k8s itself but in a 3rd party lib.

aojea · 2020-03-30T08:24:02Z

However ipv6-only and dual-stack are in "alpha"

ipv6-only is beta since 1.18 😄

andrewsykim · 2020-03-30T15:16:27Z

/assign

andrewsykim · 2020-04-02T21:42:15Z

/remove-triage unresolved

andrewsykim · 2020-04-02T21:42:43Z

Thanks @rikatz just waiting on moby/ipvs#15 now

EvanPrivate · 2020-04-03T02:58:15Z

same issue,sloved by update kernel to 5.X

duylong · 2020-04-03T07:23:58Z

I didn't want to wait, I updated to kernel-lt in the version 4.4 . The problem is solved on my side :)

andrewsykim · 2020-04-03T20:24:05Z

Thanks for confirming. We'll still try to get moby/ipvs#15 in since I'm sure other folks with older kernels will run into this issue.

andrewsykim · 2020-04-03T20:24:23Z

/retitle parseIP error with IPVS proxy

moweiraul · 2020-04-17T03:10:21Z

upgrade your system kernel to 4.xx edition

andrewsykim · 2020-04-27T19:58:29Z

FYI: moby/ipvs#15 just merged, need to run some validation & cut a new release (v1.0.1).

andrewsykim · 2020-04-28T14:34:28Z

FYI #90555

andrewsykim · 2020-04-28T14:44:35Z

/retitle DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7

andrewsykim · 2020-05-01T18:28:51Z

v1.18 cherry-pick #90678

Duanzhiwei · 2020-07-27T02:24:52Z

Hi,

Since my upgrade to 1.18 version, I have errors in kube-proxy:

E0326 13:14:23.847364       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847388       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:53/UDP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847479       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847501       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:53/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847595       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847617       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::a]:9153/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 221 232 251 54 204 98 3 124]
E0326 13:14:23.847706       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 7]
E0326 13:14:23.847728       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::7964]:443/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 7]
E0326 13:14:23.847813       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 41]
E0326 13:14:23.847835       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::dc23]:80/TCP, err: parseIP Error ip=[253 0 0 16 2 69 0 0 192 187 182 147 174 207 103 41]
E0326 13:14:23.848063       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[253 221 172 173 0 21 1 42 2 80 86 255 254 177 6 5]
E0326 13:14:23.848085       1 proxier.go:1192] Failed to sync endpoint for service: [fd00:10:96::1]:443/TCP, err: parseIP Error ip=[253 221 172 173 0 21 1 42 2 80 86 255 254 177 6 5]
...

I have ipv4/ipv6 dualstack enable. No problem with cluster and IPVS works despite errors.

Do you have also this issue ?

OS: RHEL7
Kubernetes version (use kubectl version):

Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}```

rikatz · 2020-07-27T02:50:50Z

Hi, it seems that you're using v1.18.0 and this has been corrected in v1.18.3, can you please update and check?

Tks

duylong added the kind/bug Categorizes issue or PR as related to a bug. label Mar 26, 2020

k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Mar 26, 2020

k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Mar 26, 2020

liggitt mentioned this issue Mar 27, 2020

upgrade to 1.18.0，ipvs do not sync endpoint error: parseIP Error #89561

Closed

liggitt changed the title ~~parseIP Error with kube-proxy~~ 1.18.0: parseIP Error with kube-proxy Mar 27, 2020

rikatz mentioned this issue Mar 27, 2020

Make IPVS errors more verbose #89597

Closed

k8s-ci-robot added the triage/unresolved Indicates an issue that can not or will not be resolved. label Apr 2, 2020

k8s-ci-robot removed the triage/unresolved Indicates an issue that can not or will not be resolved. label Apr 2, 2020

k8s-ci-robot changed the title ~~1.18.0: parseIP Error with kube-proxy~~ parseIP error with IPVS proxy Apr 3, 2020

rikatz mentioned this issue Apr 6, 2020

Add error messages to IPVS module #89896

Merged

SataQiu mentioned this issue Apr 7, 2020

Self nominate SataQiu as a sig-network reviewer #89924

Closed

uablrek mentioned this issue Apr 12, 2020

Kube-proxy/ipvs;Frequently cannot simultaneous access clusterip and endpoint ip(real server) in pod #90042

Closed

uablrek mentioned this issue Apr 18, 2020

kube-proxy ipvs mode does not update service endpoint ip when node fail #89392

Closed

liggitt changed the title ~~parseIP error with IPVS proxy~~ DualStack / IPv6-only: parseIP error with IPVS proxy Apr 18, 2020

liggitt added the area/ipv6 label Apr 18, 2020

fanux mentioned this issue Apr 21, 2020

Failed to sync endpoint for service labring/sealos#321

Closed

SataQiu mentioned this issue Apr 26, 2020

when I delete pods, the pods ip has been changed.but ipvs rule not change, and svc can't visit. #90435

Closed

andrewsykim mentioned this issue Apr 28, 2020

update github.com/moby/ipvs to v1.0.1 to fix IPVS compatiblity issue with older kernels #90555

Merged

k8s-ci-robot changed the title ~~DualStack / IPv6-only: parseIP error with IPVS proxy~~ DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7 Apr 28, 2020

k8s-ci-robot closed this as completed in #90555 May 1, 2020

andrewsykim mentioned this issue May 1, 2020

[v1.18] Move ipvs lib to third_party/forked and fix address family bug present in old kernels #90678

Merged

This was referenced Jul 6, 2020

IPv6 NodePort not binding with ipvs #92412

Closed

Unable to curl service using IPv6 address on kubernetes multi-node setup using calico cn projectcalico/calico#3737

Closed

DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7 #89520

DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7 #89520

Comments

duylong commented Mar 26, 2020

neolit123 commented Mar 26, 2020

liggitt commented Mar 27, 2020 • edited

SataQiu commented Mar 27, 2020

aojea commented Mar 27, 2020 • edited

uablrek commented Mar 27, 2020

uablrek commented Mar 27, 2020

duylong commented Mar 27, 2020 • edited

SataQiu commented Mar 27, 2020

uablrek commented Mar 27, 2020

SataQiu commented Mar 27, 2020

uablrek commented Mar 27, 2020 • edited

uablrek commented Mar 27, 2020

rikatz commented Mar 27, 2020

SataQiu commented Mar 28, 2020 • edited

SataQiu commented Mar 28, 2020

uablrek commented Mar 30, 2020

uablrek commented Mar 30, 2020

uablrek commented Mar 30, 2020 • edited

uablrek commented Mar 30, 2020

duylong commented Mar 30, 2020

uablrek commented Mar 30, 2020

aojea commented Mar 30, 2020 • edited

andrewsykim commented Mar 30, 2020

andrewsykim commented Apr 2, 2020

andrewsykim commented Apr 2, 2020

EvanPrivate commented Apr 3, 2020

duylong commented Apr 3, 2020

andrewsykim commented Apr 3, 2020

andrewsykim commented Apr 3, 2020

moweiraul commented Apr 17, 2020

andrewsykim commented Apr 27, 2020

andrewsykim commented Apr 28, 2020

andrewsykim commented Apr 28, 2020

andrewsykim commented May 1, 2020

Duanzhiwei commented Jul 27, 2020

rikatz commented Jul 27, 2020

liggitt commented Mar 27, 2020 •

edited

aojea commented Mar 27, 2020 •

edited

duylong commented Mar 27, 2020 •

edited

uablrek commented Mar 27, 2020 •

edited

SataQiu commented Mar 28, 2020 •

edited

uablrek commented Mar 30, 2020 •

edited

aojea commented Mar 30, 2020 •

edited