For the vSwitchNutanix standard virtual switch, does this include changing the “MAC Address Changes” to reject?
While I understand that the vSwitch shouldn’t be altered, we have a requirement for setting it to reject. If I leave it as is, I have to provide strong justification for doing so. Can you provide additional information on what impact it would have on functionality?
Thank you!
@AChurn The vSwitchNutanix is used for local communication between the Controller VM and the ESXi host. It has no uplinks. The packets between VM and hyperviosr do not go through any network cables connecting to the physical network devices. Based on that I would say definitely leave it alone.
Let me know if this addresses your concerns or you need further clarifications
Regards,
Said
Hi @AChurn
As @sbarab mentioned that vSwitchNutanix is an Internal Standard Switch for the communication between and the CVM and the ESXi Host.
It is designed and configured according to Nutanix architecture.
The Mac Address Policy or any Security Policy configured on the Nutanix Switch won’t have any direct security impact on the user VMs running in your infrastructure but Nutanix recommends not to alter any configuration setting related to vSwitchNutanix.
Do you have a particular reason or company guidelines regarding this specific configuration?
@sbarab@HITESH0801
Thank you both for your replies. The MAC Address Changes being set to allow is a CAT I finding in DISA’s ESXi STIG. There are other settings related to vSwitch configurations that were easier to justify due to being CAT II or III and because the documentation provided by Nutanix on the support portal has been an outstanding reference.
When I submit a request for an exception to policy (STIG), one of the main questions I need to answer is, “If denied, what is the impact?” A good example would be SSH being enabled. It is configured according to Nutanix architecture and if disabled, the CVMs are unable to communicate and the cluster stops functioning.
I might reach out to DISA to see if they have different guidance for situations like this where the vSwitch is used for internal communication and has no uplink(s).
@AChurn As you know this “ssh” communication allows information exchange between the hyperviosr and controller VM (CVM) which controls all I/O to the storage disks in the node.
Let us know how it goes, I am curious if they will come up with a reason not grant this exception for our internal vSwitch.
Can the name of the portgroup where the CVM management interfaces live be change from the default ‘VM Network’? Normally when I deploy ESXi, this default portgroup that vSphere creates is the first thing I delete. But since the management interface of the CVMs lives there, I would like to give the portgroup a name that’s more appropriate.
Hi Pls refer Below KB guide which describes why you should not rename or change CVM portgroup
https://portal.nutanix.com/page/documents/kbs/details?targetId=kA0600000008ge2CAA
Hope this helps you