Networking Linux VMs on an M1 Mac with 10GB trunk and 802.1q vlans

Discussion in 'Parallels Desktop on a Mac with Apple silicon' started by whistl034, Mar 21, 2023.

  1. whistl034

    whistl034 Junior Member

    Messages:
    10
    My Max Studio with M1 Max running MacOS Ventura 13.2.1 and Parallels 18.2.0 has a 10 gig ethernet connection that is an 802.1q VLAN trunk. There are only a few vlans, home (vlan 10), iot (20), and lab (40) configured.

    MacOS has built-in vlan support, so the host has no issues connecting to any external systems on the configured vlans, including Ubuntu servers with 802.1q trunks and vlan interfaces. I mention this to demonstrate I already know how to configure Ubuntu via netplan, because this works. The problem is only with the Parallels guests that try to use any of the vlans.

    When I run Linux VMs (Ubuntu 22.04), the only guest network configuration I can get to work properly is a "Shared Network" interface, which prevents the VM from being isolated to, or offering any services on any vlan. When I bridge a guest to the Mac's "home", "iot" or "guest" vlan interfaces, nothing works. When I bridge the guest interface to the Ethernet trunk itself and configuring vlan interfaces (the same way I do on external hosts), the guests are able to ping all other vlan members except the host Mac itself.

    Ping normally sends small packets. Whenever I try to do anything that uses large packets, it hangs. If I try to ssh from the guest into a remote host, or try to run software updates (sudo apt update), the network connection hangs as soon as a large packet is sent. I think something isn't setup to handle the 1518 byte MTU that a 802.1q trunk requires (18 bytes for vlan id + 1500 bytes of Layer 2 ethernet packet).

    If the Mac's ethernet has a static IP assigned, and you bridge to it, the guest and the host can communicate. If it's a trunk with no IP, and both OSs have to setup VLANs to communicate on the network, the guest cannot communicate properly. The host works fine with external servers, the guest can only ping external servers.

    Anyone else know to configure Parallels to use 802.1q VLANs?

    whistl
     
  2. whistl034

    whistl034 Junior Member

    Messages:
    10
    Update: I reached out to tech support, they are trying to reproduce the problem. Tonight I provided additional feedback.
    It turns out, on the Linux VM, if I drop the VLAN MTU to 1468, I can access remote hosts. Something in the Parallels bridge software is restricting the MTU of 802.1q vlans so it doesn't work on bridged interfaces. Maybe increasing the linux mtu of the trunk interface will work too. Damn it, now I need to try that.
     
  3. whistl034

    whistl034 Junior Member

    Messages:
    10
    Update: The MTU only has to drop to 1496 bytes. The 802.1q vlan id tag will add 4 bytes to the normal 1500 byte ethernet frame. Something between the guest and the host's network interface is truncating, or dropping, frames over 1500 bytes. Setting MTU to 1496 works around that limitation.

    # cat /etc/netplan/10-v3.yaml
    # This is the network config written by 'subiquity'
    network:
    version: 2
    renderer: networkd
    ethernets:
    enp0s5:
    dhcp4: false
    dhcp6: false
    enp0s6:
    dhcp4: false
    dhcp6: false
    vlans:
    vlan10:
    id: 10
    link: "enp0s6"
    dhcp4: true
    dhcp6: true
    mtu: 1496
    vlan40:
    id: 40
    link: "enp0s6"
    dhcp4: true
    dhcp6: true
    mtu: 1496
     
  4. whistl034

    whistl034 Junior Member

    Messages:
    10
    Parallels Support closed my base as "resolved" and my Mac still can't talk to any VMs via vlans. The Mac can reach it's default gateway and all remote systems on vlan 10, but not any of the Mac's VMs that bridge to the Macs Ethernet port, and configure vlan10 internally. The VMs can reach the default gateway, each other, and remote systems on vlan10. The mac and the vms cannot ping, ssh, curl, etc to each other.

    Secondly, the workaround I located (which was to lower the vlan's IP interface MTU to 1496) is just a workaround. The problem is NOT resolved! Something is wrong with Parallels networking stack.
     
  5. Pramesh Boodadoo

    Pramesh Boodadoo Staff Member

    Messages:
    532
    Hello,
    Please note that the case (#4*****6) has been re-opened, and we will continue investigating on this issue.
    Thank you.
     

Share This Page