IPv6 connectivity to pod with port mapping broken #2879
Comments
|
@QxBytes i guess this is fixed now.. can you close it comment which release has the fix for this issue |
|
looks like hns issue not resolved. keeping it open |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
|
This issue is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days |
What happened:
Cannot connect to pod from node through node ipv6 + port when port mapping policy specified in dualstack
What you expected to happen:
Connection succeeds
How to reproduce it:
Repro:
Create a dualstack cluster with windows nodes
Create a pod with port mapping policy (but no host ip)
Node shell onto the node with the pod
Test-netconnection to the :
If using the ipv4 address of the node, there is a success, but using the ipv6 address fails
Get-HnsEndpoints should show two cni policies, one for ipv4, and one for ipv6 and so the connection should succeed
Orchestrator and Version (e.g. Kubernetes, Docker):
Operating System (Linux/Windows):
Windows
Kernel (e.g.
uanme -afor Linux or$(Get-ItemProperty -Path "C:\windows\system32\hal.dll").VersionInfo.FileVersionfor Windows):Anything else we need to know?:
This issue appeared after using a binary with #2852 applied
Suspected HNS issue (currently being looked at)
The text was updated successfully, but these errors were encountered: