You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The four bytes of an IPv4 address can be losslessly converted to an eight byte hex string. The 16 bytes of an IPv6 address need to be hashed, as before.
The tunnel names for IPv4 addresses will be shorter, and can be easily converted back to the original IP address. Not sure if that's an undesirable side effect. If yes, the four IPv4 bytes could be hashed, as before, although I suppose that this is not a problem at all?
What did you expect to happen?
Tunnel name generation should not have the potential to lead to a hash collision that could cause tunnels to not be created properly for IP addresses that are the same numerically in different parts of the octet.
Additional context
We currently rely on tunnel name generation being predictable in order to clean up old tunnels. This means that we would either need to implement fall-back logic for matching tunnels for a set of releases, or we would need to couple this change to a release where we advise cluster administrators to do a rolling reboot in conjunction with the kube-router rollout (advice that is usually either missed, or pushed back against by community members).
The text was updated successfully, but these errors were encountered:
What happened?
Related to: #1745 (comment), the current code looks like:
@twz123 points out: This would mean that "21.3.0.4" hashes to the same tunnel as "2.13.0.4". Is that something that kube-router should care about?
Wouldn't it be more straight forward to operate on the IP address bytes, instead of their string representation? E.g. like this:
The four bytes of an IPv4 address can be losslessly converted to an eight byte hex string. The 16 bytes of an IPv6 address need to be hashed, as before.
The tunnel names for IPv4 addresses will be shorter, and can be easily converted back to the original IP address. Not sure if that's an undesirable side effect. If yes, the four IPv4 bytes could be hashed, as before, although I suppose that this is not a problem at all?
What did you expect to happen?
Tunnel name generation should not have the potential to lead to a hash collision that could cause tunnels to not be created properly for IP addresses that are the same numerically in different parts of the octet.
Additional context
We currently rely on tunnel name generation being predictable in order to clean up old tunnels. This means that we would either need to implement fall-back logic for matching tunnels for a set of releases, or we would need to couple this change to a release where we advise cluster administrators to do a rolling reboot in conjunction with the kube-router rollout (advice that is usually either missed, or pushed back against by community members).
The text was updated successfully, but these errors were encountered: