The vSwitch does not learn MAC address like a physical switch, and normally this is not a problem since it means that all unknown unicast MAC addresses are "outside" the vSwitch and should be delivered to the physical network. I think this occurs because the vSwitch only knows all the MACs of virtual machines within the ESX environment, it doesn't learn MAC addresses like a physical real switch and it discards packets sent to unknown unicast MAC addresses (broadcast traffic instead is passed). Is available in VMware an emulation of a real switch performing that I am trying to do? How about Cisco Nexus 1000V or Open vSwitch? My question is, is it possible to solve this situation without configuring the port of the switch in promiscuous mode? This is a workaround used by many people in my situation (see this document as example - ). If the port of the vSwitch related to the trunk mode is configured in promiscuous mode, the above ARP reply is received by the remote client and the ping succeeds. I think this occurs because the vSwitch only knows all the MACs of virtual machines within the ESX environment, it doesn't learn MAC addresses like a physical real switch and it discards packets sent to unknown unicast MAC addresses (broadcast traffic instead is passed).Am I wrong? This last packet doesn't pass the vSwitch, so it isn't received by the remote client and the ping fails. The host VM2 sends an ARP reply directly to the MAC address of the remote client. Īfter an openvpn connection the remote client cannot ping VM2.Īnalizing traffic with Wireshark on the VM2 I've noticed that an ARP request leaves from the remote client MAC to the destination host interface of VM2 (broadcast ARP request). A software on VM1 will pack frames compliant to 8021q and will send out them through the second NIC. In this manner frames from different VLAN will be received by the vSwitch through the trunk link and will be sent out to the right vlan ports. Only one port, that one related to the second NIC of the VM1 is configured in trunk mode (VLANID 4095). VM2 has one NIC, configured to be within the vlan10.Īll the ports of the VMware vSwitch (except one) are configured to multiplex and demultiplex level 2 traffic based on a VLANID (for example VLAN10). VM1 has two NICs, one configured to be contacted remotely by remote openvpn clients and one configured to send frames compliant to vlan 8021q protocol (This is obtained by a software related to openVpn) to internal vlans.
VM1 can ping VM2 without any problem (supposing vlan 10 traffic). I've deployed an OpenVpn infrastructure (configured in bridging mode) within a VMmare ESX4 environment.Ī remote client connects to the OpenVpn server (VM1), VM1 also owns an interface where traffic passes in tagged mode complaint to vlan 8021q, VM2 owns a interface on the vlan10.
0 kommentar(er)
