Discovering VM MAC Address

[luv_nsx]

How does NSX Manager discover a VM's MAC address? In other words, if you create a rule under Ethernet (L2) section of Firewall, the rules are not pushed down to the host. I am assuming because NSX M doesn't know the MAC addresses of the VM. Therefore how does it learn that?

Also, when should one use rules that are defined in the Ethernet section?

[rajeevsrikant]

The sw-sec module  is responsible for learning Layer 2 (MAC) for VM IP addresses through ARP & DHCP.

What is the IP Detection mechanism which you are using ?

[luv_nsx]

So are you saying the sw-sec module is responsible for telling NSX Manager what the MAC address is of a given VM? If that's the case, then howcome when I configure L2 rules in DFW, they don't show up on the host? I assumed it was because NSX M couldn't learn the MAC address of the VMs.

For IP detection, just using VM Tools.

[hansroeder]

The sw-sec module is part of the Distributed Firewall IOChain, where slot 0 is the dvFilter, slot 1 is the sw-sec module, slot 2 is the Distributed Firewall, etc. It is this module that actually learns about MAC and IP addresses, which also makes it possible to query the NSX Controllers for information about these things, without the need for using broadcast.

What happens when you set the IP Detection Type to ARP Snooping (see VMware NSX for vSphere 6.2 Documentation Center)?

[cnrz]

Is it possible that the Proxy Arp Mechanism which uses arp or DHCP protocols to discover IP and MAC, it may be enabled/disabled on the Logical Switch level? Also does the rules contain MAC-Set or object level?

Thefollowing links may be helpful:

http://www.sneaku.com/2015/08/28/nsx-v-6-2-whats-new-ip-discovery/

New IP address discovery mechanisms for VMs: Authoritative enforcement of security policies based on VM names or other vCenter-based attributes requires that NSX know the IP address of the VM. In NSX 6.1 and earlier, IP address discovery for each VM relied on the presence of VMware Tools (vmtools) on that VM or the manual authorization of the IP address for that VM. NSX 6.2 introduces the option to discover the VM’s IP address using DHCP snooping or ARP snooping. These new discovery mechanisms enable NSX to enforce IP address-based security rules on VMs that do not have VMware Tools installed.

Vxlan arp suppression mechanism, using swsec updates the Controllers through VM IP Update messages (which includes IP and MAC address of the VM. Since the rule-set on the Vnic should contain only IP address and MAC address.

https://telecomoccasionally.wordpress.com/2014/10/27/nsx-v-under-the-hood-vxlan-arp-suppression/

NSX Distributed Firewall Deep Dive – VMware Professional Services

Slot 1: sw-sec (Switch Security): sw-sec module learns VMs IP and MAC address. sw-sec is critical component capture DHCP Ack and ARP broadcast message and forward this info as unicast to NSX Controller to perform the ARP suppression feature. sw-sec is the layer where NSX IP spoofgurd is implemented,

Cluster, DC, VDS port-group, Logical Switch, IPSets, Resource Pool, vAPP, VM, vNIC and Security Groups. The NSX firewall enforce point at the VMware-sfw can only understand IP address or MAC address.

NSX Edge and L2 (MAC-Set) Rule not working

[luv_nsx]

The sw-sec module only informs the Controllers of the MAC addresses. The question is, when the controllers are not deployed (such as when only doing micro-segmentation), how does NSX Manager learn the MAC address of the VM?

[cnrz]

NSX dFW needs to convert the abstracted Vcenter object bases rules to IP address during publishing the rules to the Vnic. For example "All Vms with name including WEB" Security Group at the end converted to an IP based firewall rule which includes the IP addresses of all VMs, and if the rulebase is listed on the NIC, only IP addresses are observed. Both mechanisms of VMware Tools and sw-sec updating the IP addresses of the VM to the controller may be ok for IP.

Also SpoofGuard mechanism needs to learn IP and MAC address of the VM (which also feature of NSX Manager), on the NSX Administration Guide it mentions MAC address is collected from the VMX File and Vsphere SDK as they are already assigned by the Vcenter during the Creation of the VM, so NSX manager may learn MAC address from the Vmware Tools or Vcenter directly. So even Controllers are not used these MACs may be learned. But whether they (Macs learned through VM Tools)  are used by the  L2 FW Rule may need to be tested as most deployments use Controllers and Vm Tools MAC addresses learned through VM tools may not be used by the software for L2 dFW

https://pubs.vmware.com/NSX-6/index.jsp?topic=%2Fcom.vmware.nsx.admin.doc%2FGUID-06047822-8572-4711-...

You create a SpoofGuard policy for specific networks that allows you to authorize the IP addresses reported by VMware Tools and alter them if necessary to prevent spoofing. SpoofGuard inherently trusts the MAC addresses of virtual machines collected from the VMX files and vSphere SDK. Operating separately from Firewall rules, you can use SpoofGuard to block traffic determined to be spoofed.

Doesn't  the L2 Firewall Rule already contain MAC address during the Rule configuration already? For example a rule such as "Permit  traffic from MAC A.A.A to MAC B.B.B, and Block traffic from A.A.A to MAC C.C.C". Here this rule when applied to the Vnic of VM with Mac A.A.A, then the NSX Manager doesn't need to discover to which VM the C.C.C belongs, as it is already entered during Rule configuration. If dynamic objects is used, then as IP addresses are discovered and used dynamically, Mac may not be needed.

[DaleCoghlan]

The reason you don't see unnecessary L2 rules on the filter of a particular VM and you only see the L2 rules that are applicable to that VM is because of the L2 Optimization feature which is enabled by default on the DFW. This is enforced at the host level when the rules are programmed into the filter by vsfwd.

The MAC address of the VMs are learnt from vCenter (from the VM vmx files).

Dale