Details
-
Bug
-
Resolution: Fixed
-
Critical
-
7.0.0-Beta1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.4, 7.0.5, 7.1.0, 7.1.1, 7.1.2, 7.2.0, 7.1.3, 7.2.1, 7.1.5, 7.2.4, 7.0.6
-
Untriaged
-
0
-
No
Description
Found via unit test + a random luck that the IPs returned by localhost look up via net.LookupIP happens to return ipv4 in front of ipv6 address.
Essentially if the golang call of net.LookupIP returns addresses in a list and the IPv4 address is in the front of the list, and IPv6 only mode is in place, XDCR will return an invalid IPv6 address of:
[127.0.0.1]
============== Test case start: TestEnforceIP =================
|
NEIL DEBUG nonActive activeHostName connStr localhost
|
NEIL DEBUG addrs [127.0.0.1 ::1]
|
NEIL DEBUG ipv6 addr connStr localhost port 0 portErr No port number
|
NEIL DEBUG ipv4 blocked true ipv6 blocked false mapping connStr localhost isFullEncryption false to [127.0.0.1]
|
============== Test case done: TestEnforceIP =================
|
--- FAIL: TestEnforceIP (0.00s)
|
remote_cluster_ref_test.go:331:
|
Error Trace: remote_cluster_ref_test.go:331
|
Error: Not equal:
|
expected: "[::1]"
|
actual : "[127.0.0.1]"
|
|
Diff:
|
--- Expected
|
+++ Actual
|
@@ -1 +1 @@
|
-[::1]
|
+[127.0.0.1]
|
Test: TestEnforceIP
|
We haven't seen this in the field yet probably because not many people are using IPv6 only mode, and considering that Capella currently uses IPv4 only mode.
However, if IPv6 only mode is ever used, this could lead to continuous HA outages as the MyConnectionStr() method is used throughout the code as a remote cluster reference string getter.
Issue | Resolution |
Running ipv6 only mode + non-encrypted remote resulted in invalid IP addresses being returned leading to connection issues. | A valid IP address is now returned. |
Attachments
Issue Links
- is a backport of
-
MB-57411 XDCR - ipv6 only mode + non-encrypted remote could lead to invalid IP address returned
- Closed