This Tech Tip explains how to setup VMWare Fusion to enable isolated network segments between guests. This is particularly useful when used in conjunction with vEOS (vEOS – Running EOS in a VM).
When vEOS instances are run in VMWare Fusion and share the same virtual network interface on the host, for example the hostonly interface, all VMs will appear to be connected to the same segment. This is fine for testing routing and usual EOS feature but poses a problem when testing a feature that depends on the VM or vEOS instance only being able to see one other VM over a link. Consider the topology below.
The red lines represent connections to the virtual management switch, blue line represent where data traffic will flow.
If we were to create an MLAG (MLAG – Basic Configuration), between vEOS1 and vEOS2, in order for this to be properly presented to vEOS3, the links between the devices have to be emulated as isolated links otherwise vEOS1, vEOS2 and vEOS3 would appear to be connected to the same segment, similarly to connecting them to a hub. Therefore, a solution is needed when running virtual instances of EOS.
VMWare Fusion Networking
VMWare Fusion provides some nice features and easy to setup networking when deploying VMs on a host. However, when a user wants to get more advanced it can become a bit more difficult. A lot of the advanced configuration files are stored in the following locations depending on the VMware Fusion version:
- VMWare Fusion 3.x – /Library/Application Support/VMware Fusion
- VMware Fusion 4.x – /Library/Preferences/VMware Fusion/
On inspection of the default ‘networking’ file you will see:
VERSION=1,0 answer VNET_1_DHCP yes answer VNET_1_DHCP_CFG_HASH 9368EABA67CDCA382B9E63E846DCDCCE314D6D1A answer VNET_1_HOSTONLY_NETMASK 255.255.255.0 answer VNET_1_HOSTONLY_SUBNET 172.16.105.0 answer VNET_1_VIRTUAL_ADAPTER yes answer VNET_8_DHCP yes answer VNET_8_DHCP_CFG_HASH 6432C3C11E1317B4096E99CFE21679DC8C9486D0 answer VNET_8_HOSTONLY_NETMASK 255.255.255.0 answer VNET_8_HOSTONLY_SUBNET 172.16.77.0 answer VNET_8_NAT yes answer VNET_8_VIRTUAL_ADAPTER yes
And when configuring a guest network adapter.
The configuration lines correspond to the GUI options:
VNET_1 = (Host Only)
VNET_8 = (NAT)
By editing these lines we can change the subnet from which IP addresses are assigned from the VMWare built in DHCP server. By setting ‘VNET_X_VIRTUAL_ADAPTER yes’, this exposes the adapter to the host and can be visible when running ‘ifconfig’ on the host.
Seans-MacBook-Pro:~ sean$ ifconfig vmnet1: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500 ether 00:50:56:c0:00:01 inet 172.16.105.1 netmask 0xffffff00 broadcast 172.16.105.255 vmnet8: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500 ether 00:50:56:c0:00:08 inet 172.16.77.1 netmask 0xffffff00 broadcast 172.16.77.255
To activate any changes made to this file; in VMWare Fusion 4, quit the application and restart. In VMWare Fusion 3, the networking component is run as a service and must be restarted using the following command:
/Library/Application\ Support/VMWare\ Fusion/boot.sh –restart
Adding Segments to VMWare Fusion
To add networking segments, the networking file must be extended. An example is given below that defines a number of additional VNETs.
VERSION=1,0 answer VNET_1_DHCP yes answer VNET_1_DHCP_CFG_HASH 96879A0C7265B8CEF059D0A35F64859F8DBA14CF answer VNET_1_HOSTONLY_NETMASK 255.255.255.0 answer VNET_1_HOSTONLY_SUBNET 172.16.140.0 answer VNET_1_VIRTUAL_ADAPTER yes answer VNET_2_DHCP no answer VNET_2_NAT no answer VNET_2_VIRTUAL_ADAPTER no answer VNET_3_DHCP no answer VNET_3_NAT no answer VNET_3_VIRTUAL_ADAPTER no answer VNET_4_DHCP no answer VNET_4_NAT no answer VNET_4_VIRTUAL_ADAPTER no answer VNET_5_DHCP no answer VNET_5_HOSTONLY_NETMASK 255.255.255.0 answer VNET_5_HOSTONLY_SUBNET 172.16.130.0 answer VNET_5_NAT yes answer VNET_5_VIRTUAL_ADAPTER yes answer VNET_6_DHCP no answer VNET_6_NAT no answer VNET_6_VIRTUAL_ADAPTER no answer VNET_7_DHCP no answer VNET_7_NAT no answer VNET_7_VIRTUAL_ADAPTER no answer VNET_8_DHCP yes answer VNET_8_DHCP_CFG_HASH 4CDD547269493045DFF5C1E34E73B866E0EAA02D answer VNET_8_HOSTONLY_NETMASK 255.255.255.0 answer VNET_8_HOSTONLY_SUBNET 172.16.175.0 answer VNET_8_NAT yes answer VNET_8_VIRTUAL_ADAPTER yes answer VNET_9_DHCP no answer VNET_9_NAT no answer VNET_9_VIRTUAL_ADAPTER no answer VNET_10_DHCP no answer VNET_10_NAT no answer VNET_10_VIRTUAL_ADAPTER no answer VNET_11_DHCP no answer VNET_11_NAT no answer VNET_11_VIRTUAL_ADAPTER no
This adds all the necessary VNETs for the topology shown earlier in the post. Most of these have not been exposed to the host as there is no interaction needed from the host to the VMs, these have been created to add multiple segments to VMWare and some of the IP addresses have been changed.
Assigning Guest Adapters to VNETs
Now that multiple VNETs have been created, VMWare restarted (or service restarted), guest Ethernet adapters can be assigned to the VNETs. This involves editing the vmx file containing the guest configuration. Here is a snippet from vEOS1 vmx file:
#!/usr/bin/vmware .encoding = "ASCII" ... displayName = "vEOS_1" ... # Management0 ethernet0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.addressType = "generated" ethernet0.pciSlotNumber = "33" ethernet0.connectionType = "custom" ethernet0.vnet = "vmnet2" ethernet0.displayName = "Custom Host Only VMnet2 - Management - To vEOS1" # Ethernet1 ethernet1.present = "TRUE" ethernet1.virtualDev = "e1000" ethernet1.addressType = "generated" ethernet1.pciSlotNumber = "36" ethernet1.connectionType = "custom" ethernet1.vnet = "vmnet6" # Ethernet2 ethernet2.present = "TRUE" ethernet2.virtualDev = "e1000" ethernet2.addressType = "generated" ethernet2.pciSlotNumber = "37" ethernet2.connectionType = "custom" ethernet2.vnet = "vmnet7" # Ethernet3 ethernet3.present = "TRUE" ethernet3.virtualDev = "e1000" ethernet3.addressType = "generated" ethernet3.pciSlotNumber = "38" ethernet3.connectionType = "custom" ethernet3.vnet = "vmnet10"
By changing the ‘.connectionType’ to “custom” and then assigning the ‘.vnet’ to “vmnetXX”, this will place the Ethernet adapter in the appropriate segment (NOTE – vmnet10 links the adapter to VNET_10, this syntax must be used).
Once this is done, you will notice that the GUI shows the adapter as having a custom setting (as shown above), if any other option is chosen this will override the vmx file.
If ‘show lldp neighbours’ is run from one of the vEOS devices, you will see that only the neighbor is seen over each interface:
vEOS1#show lldp neighbors ... Port Neighbor Device ID Neighbor Port ID TTL Et1 vEOS2 Ethernet1 120 Et2 vEOS3 Ethernet1 120 Et3 vEOS3 Ethernet3 120 Ma1 vEOSMGMT Ethernet1 120
And the result is that MLAG is able to be run properly as in the topology above:
vEOS1#show mlag MLAG Configuration: domain-id : MLAG local-interface : Vlan4094 peer-address : 10.0.0.2 peer-link : Ethernet1 MLAG Status: state : Active peer-link status : Up local-int status : Up system-id : 02:0c:29:33:9e:6f MLAG Ports: Disabled : 0 Configured : 0 Inactive : 0 Active-partial : 0 Active-full : 2
Once everything is setup, another useful tool in the VMWare toolset is the vmnet-sniffer, using this following command, the above network ‘segments’ can be sniffed and the output shown on screen or sent to a pcap file readable in wireshark:
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-sniffer [-eP] [-w file] if
Where -e shows the ethernet header and -w writes to a specified file with the vmnet interface at the end such as vmnet6.