Any fix for non-working bridged IPv6 with Mac gues...

A_Consultant · ‎05-24-2016

I was asked to post this here with a promise that the VMware engineers will provide a solution (quote from email via VMware Support Request # 16111698005):

---

I recommend that you post your query on VMware Communities. The query will be reviewed and the resolution will be provided by the VMware engineers. Once again I apologize for the inconvenience caused.

---

Here's the problem as I reported it:

This is likely an in-depth problem that will need to be escalated to someone with IPv6 networking expertise in VMware Fusion. Solving this issue could also lead to significant revenue for VMware.

I'm a consultant working under contract for an organization that wants to virtualize a significant number of OS X 10.8.5 systems. Initially, the host systems will also be running OS 10.8.5 but, ultimately, will be updated to something newer.

Everything is working well on VMware except for bridging of multi-homed, manually-defined IPv6 addresses. However, this is a "must have" requirement for this project. It should also be noted that Parallels does not have this problem.

I am in need of a solution where the following tests won't fail ...

From external test system 1:

- ping6 -v x:y:z:1::99

- ping6 -v x:y:z:4::99

- ping6 -v x:y:z:5::99

From external test system 2:

- ping6 -v x:y:z:1::99

- ping6 -v x:y:z:4::99

- ping6 -v x:y:z:5::99

... in the following configuration ...

-----

Note that we only test and care about manually configured addresses. The IPv6 x:y:z:? prefix indicates a publicly routable prefix (e.g., 2001:abcd:1234:?).

The virtual host is running OS X 10.8.5 and has the following host-native networking configuration:

- 1 ethernet interface (en0) configured with 3 VLANs: VLAN 1, VLAN 4 and VLAN 5

+ VLAN 1 (on en0):

* IPv4 addr: 172.16.1.10

* IPv4 router & DNS: 172.16.1.1

* IPv4 Subnet mask: 255.255.255.0 (LAN1 is 172.16.16.0/24)

* IPv6 addr is x:y:z:1::10 (LAN1 is x:y:z:1::/64)

* IPv6 router & DNS are x:y:z:1::1

+ VLAN 4 (on en0):

* IPv4: OFF

* IPv6 addr: x:y:z:4::10 (LAN4 is x:y:z:4::/64)

* IPv6 router and DNS are x:y:z:4::1

+ VLAN 5 (on en0):

* IPv4: OFF

* IPv6 addr: x:y:z:5::10 (LAN5 is x:y:z:5::/64)

* IPv6 router and DNS are x:y:z:5::1

On the above-configured virtual host, a virtualized system that's running OS X 10.8.5 in VMware Fusion 7.1.3 (3204469, dated 2015-11-2) that has the following network configuration:

- 3 VMware network adapters defined:

+ adapter 1: bridged to VLAN 1 (en0)

+ adapter 2: bridged to VLAN 4 (en1)

+ adapter 3: bridged to VLAN 5 (en2)

- virtualized system's networking configured as:

+ LAN 1 (on en0):

* IPv4 addr: 172.16.1.99

* IPv4 router and DNS are 172.16.1.1

* IPv4 Subnet mask: 255.255.255.0 (LAN1 is 172.16.16.0/24)

* IPv6 addr: x:y:z:1::99 (LAN1 is x:y:z:1::/64)

* IPv6 router and DNS are x:y:z:1::1

+ LAN 4 (on en1):

* IPv4: OFF

* IPv6 addr: x:y:z:4::99 (LAN4 is x:y:z:4::/64)

* IPv6 router and DNS are x:y:z:4::1

+ LAN 5 (on en2):

* IPv4: OFF

* IPv6 addr: x:y:z:5::99 (LAN5 is x:y:z:5::/64)

* IPv6 router and DNS are x:y:z:5::1

External test system 1 is running OS X 10.8.5 and has the following networking configuration:

- 1 ethernet interface (en0) configured with 3 VLANs: VLAN 1, VLAN 4 and VLAN 5

+ VLAN 1 (on en0):

* IPv4 addr: 172.16.1.100

* IPv4 router and DNS are 172.16.1.1

* IPv4 Subnet mask: 255.255.255.0 (LAN1 is 172.16.16.0/24)

* IPv6 addr: x:y:z:1::100 (LAN1 is x:y:z:1::/64)

* IPv6 router and DNS are x:y:z:1::1

+ VLAN 4 (on en0):

* IPv4: OFF

* IPv6 addr: x:y:z:4::100 (LAN4 is x:y:z:4::/64)

* IPv6 router and DNS are x:y:z:4::1

+ VLAN 5 (on en0):

* IPv4: OFF

* IPv6 addr: x:y:z:5::100 (LAN5 is x:y:z:5::/64)

* IPv6 router and DNS are x:y:z:5::1

External test system 2 is running OS X 10.8.5 and has the following networking configuration:

- 1 ethernet interface (en0) configured as:

* IPv4 addr: 172.16.1.200

* IPv4 router and DNS are 172.16.1.1

* IPv4 Subnet mask: 255.255.255.0 (LAN1 is 172.16.16.0/24)

* IPv6 addr: x:y:z:1::200 (LAN1 is x:y:z:1::/64)

* IPv6 router and DNS are x:y:z:1::1

Obviously, this setup also requires a suitable switch with the applicable VLAN configuration, a router configured to perform VLAN-to-VLAN routing and a DNS.

-----

Test-setup comments ...

---

I'd guess that this setup would also fail without the use of VLANs -- i.e., with either mixed subnets on the same "wire" or with different NICs for different LANs on the virtual host. I did run a "quick 'n dirty" test using an additional Thunderbolt to Ethernet adapter and it did seem to fail the same way, but that test was not thorough. Still, it might be easier to test a multiple-NIC virtual host first, with the hope that that could prevent having to setup a VLAN environment, if you don't already have it. It's relatively easy for me to test any proposed solution in the VLAN setup I have.

It's also true that the same kinds of failures will be seen when there are only 2 IPv6 addresses/LANs configured, instead of 3, but my testing was for the most common real scenario which requires 3-LAN/3-IP support.

Failure details ...

---

In reality, if the routing is working correctly, both external test systems should always yield the same results.

What we're seeing is completely "flakey" results in that "ping6 -v" nearly always fails with "Destination Host Unreachable" and that the x:y:z:?::99 addresses are not in the router's NDP table.

I say "nearly always" because sometimes 1 (or rarely even 2) of the x:y:z:?::99 IPs will be "pingable"/visible but this seems to change with each reboot and/or any network configuration updates. In addition, a non-"pingable"/non-visible x:y:z:?::99 IP will sometimes become externally "pingable"/visible after the test system's x:y:z:?::?00 IP is pinged from the virtualized system -- e.g., scenarios similar to the following occur:

- ping6 -v x:y:z:4::99 from test system 2 fails

- ping6 -v x:y:z:4::200 is run from the virtualized system and succeeds

- now ping6 -v x:y:z:4::99 from test system 2 succeeds

Speculation ...

---

(I think it's consistent that) When you look at ifconfig on the virtualized system, you'll see that the IPv6 interface that's initially "pingable" -- there's normally 1 of the 3 that'll work -- is the IP on the interface that appears first in the list of interfaces produced by ifconfig.

It seems that the bridging is somehow only passing router advertisements for one of the multi-homed, manually-configured IPv6 addresses.

If we can get this to work, I'd be happily recommending VMware for this project. Assuming the project proceeds, it could mean significant business for VMware (my confidentiality agreement prohibits me from providing details about the project).

nancyz · ‎05-29-2016

Hi There，

Welcome to Fusion community.

The virtual host is running OS X 10.8.5 and has the following host-native networking configuration:

- 1 ethernet interface (en0) configured with 3 VLANs: VLAN 1, VLAN 4 and VLAN 5

Do you mean you configured a truck port and let your ethernet interface plug to that port?

A_Consultant · ‎05-30-2016

Re: Do you mean you configured a truck port and let your ethernet interface plug to that port?

---

Sorry, but I don't understand the question ... I don't know what a "truck port" is (but we have a sea-going container port, nearby ... and it gets lots of container trucks at the port! #;-)).

The test system upon which VMware is running (the virtual host) has the exact networking configuration indicated ... i.e., it's an iMac and there's the normal motherboard ethernet. There are 3 VLANs configured (as detailed) and all 3 of the VLANs are created "against" the motherboard ethernet port (OS X shows "Ethernet" as the interface that's selected when adding each of the VLANs via "Manage Virtual Interfaces" in the "Network" panel of "System Preferences").

Does that clarify?

nancyz · ‎05-31-2016

sorry, A ConsultantA Consultant

Sorry, but I don't understand the question ... I don't know what a "truck port" is (but we have a sea-going container port, nearby ... and it gets lots of container trucks at the port! #;-)).

It's typo. I wanted to say 'trunk'.

I now know your environment.

A_Consultant · ‎05-31-2016

Good to hear. Never thought of that typo. Guess my brain doesn't work at full tilt after 2 in the morning.

Let me know if there's any way I can help.

nancyz · ‎06-06-2016

Hi A ConsultantA Consultant,

How about the result if add -I ,

- ping6 -v -I x:y:z:1::99?

A_Consultant · ‎06-06-2016

ping6 -v -I x:y:z:1::99 is not a valid command as '-I' requires an interface. Hoping that's what you meant (i.e., that it's not a typo and you wanted something else entirely), I ran a collection of tests and have included the results in the attached text file.

For redundency, I've also pasted the results, below (have no idea what'll happen to formatting, special characters, etc.):

---

From system that has IPv6: x:y:z:1::200

(with sanitizing search 'n replace, for security)

-----

root # ping6 -v -I en0 x:y:z:1::99

PING6(56=40+8+8 bytes) x:y:z:1::200 --> x:y:z:1::99

136 bytes from fe80::ec4:7aff:fe17:18d4%en0: Router Advertisement

64 bytes from x:y:z:1::200: Destination Host Unreachable

Vr TC Flow Plen Nxt Hlim

6 00 00000 0010 3a 40

x:y:z:1::200->x:y:z:1::99

ICMP6: type = 128, code = 0

64 bytes from x:y:z:1::200: Destination Host Unreachable

Vr TC Flow Plen Nxt Hlim

6 00 00000 0010 3a 40

x:y:z:1::200->x:y:z:1::99

ICMP6: type = 128, code = 0

64 bytes from x:y:z:1::200: Destination Host Unreachable

Vr TC Flow Plen Nxt Hlim

6 00 00000 0010 3a 40

x:y:z:1::200->x:y:z:1::99

ICMP6: type = 128, code = 0

64 bytes from x:y:z:1::200: Destination Host Unreachable

Vr TC Flow Plen Nxt Hlim

6 00 00000 0010 3a 40

x:y:z:1::200->x:y:z:1::99

ICMP6: type = 128, code = 0

^C

--- x:y:z:1::99 ping6 statistics ---

17 packets transmitted, 0 packets received, 100.0% packet loss

From VMware virtual host system that has IPv6: x:y:z:1::10

(with sanitizing search 'n replace, for security)

-----

root # ping6 -v -I en0 x:y:z:1::99

PING6(56=40+8+8 bytes) x:y:z:1::10 --> x:y:z:1::99