locked
Windows Server 8: DHCP Guard and Port ACLs in Hyper-V. Howto? RRS feed

  • Question

  • There are lots of sources writing about the new Hyper-V features "DHCP guard" and "Port ACLs".

    I do have a simple problem: I cannot find any ressource explaining howto actually configure these things. Is it in the current preview version?

    Thorsten

    • Edited by Thorsten _ Thursday, March 8, 2012 6:48 PM
    Thursday, March 8, 2012 6:47 PM

Answers

  • Okay, you made me go looking through the PowerShell this morning...

    DHCP Guard can be found in the NIC settings of the VM under Advanced Features.

    You will also find it in PowerShell:

    PS C:\Users\Administrator> $nic = Get-VMNetworkAdapter
    
    PS C:\Users\Administrator> $nic
    
    Name            IsManagementOs VMName                  SwitchName
    ----            -------------- ------                  ----------
    Network Adapter False          BrianEhDC.BrianEh.local
    
    
    PS C:\Users\Administrator> $nic.DhcpGuard

    The ACLs are properties of the VM NIC (technically the virtual switch port) and accessed using PowerShell:

    PS C:\Users\Administrator> Get-Command -module Hyper-V -Noun *acl*
    
    Capability      Name                                               ModuleName
    ----------      ----                                               ----------
    Cmdlet          Add-VMNetworkAdapterAcl                            Hyper-V
    Cmdlet          Get-VMNetworkAdapterAcl                            Hyper-V
    Cmdlet          Remove-VMNetworkAdapterAcl                         Hyper-V

    You will also find the AclList as a property of the virtual NIC itself.

    PS C:\Users\Administrator> $nic.Acllist


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.



    • Edited by BrianEhMVP Friday, March 9, 2012 3:44 PM
    • Marked as answer by Thorsten _ Saturday, March 10, 2012 1:02 PM
    Friday, March 9, 2012 3:43 PM

All replies

  • The documentation is still being built around much of this.

    These are VM level settings - technically port settings that travel with the VM.

    I am not sure how much I can say about them at this time.  You can definately check the PowerShell behind them it might give you some idea, but that documentation is not complete either.

    DHCP Guard is kind of self explanatory and just an on or off (AFAIK).

    ACLs involves a bit more explanation.  Think allow and deny to get started.  Remember, this is a switch port this is applied to (as a VM technically does not have a NIC patched to a port, just an association to a port).


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Thursday, March 8, 2012 8:01 PM
  • Imho you should find it on the vSwitch level; but nevertheless: could not find at anywhere, of course I checked the cmdlets too.

    Either I am blind, or it's somehow mysterious.

    Thorsten

    Friday, March 9, 2012 10:20 AM
  • Okay, you made me go looking through the PowerShell this morning...

    DHCP Guard can be found in the NIC settings of the VM under Advanced Features.

    You will also find it in PowerShell:

    PS C:\Users\Administrator> $nic = Get-VMNetworkAdapter
    
    PS C:\Users\Administrator> $nic
    
    Name            IsManagementOs VMName                  SwitchName
    ----            -------------- ------                  ----------
    Network Adapter False          BrianEhDC.BrianEh.local
    
    
    PS C:\Users\Administrator> $nic.DhcpGuard

    The ACLs are properties of the VM NIC (technically the virtual switch port) and accessed using PowerShell:

    PS C:\Users\Administrator> Get-Command -module Hyper-V -Noun *acl*
    
    Capability      Name                                               ModuleName
    ----------      ----                                               ----------
    Cmdlet          Add-VMNetworkAdapterAcl                            Hyper-V
    Cmdlet          Get-VMNetworkAdapterAcl                            Hyper-V
    Cmdlet          Remove-VMNetworkAdapterAcl                         Hyper-V

    You will also find the AclList as a property of the virtual NIC itself.

    PS C:\Users\Administrator> $nic.Acllist


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.



    • Edited by BrianEhMVP Friday, March 9, 2012 3:44 PM
    • Marked as answer by Thorsten _ Saturday, March 10, 2012 1:02 PM
    Friday, March 9, 2012 3:43 PM
  • Technically it is at the virtual switch level as a virtual nic is technically a virtual switch port.

    It is represented in the UI as a virutal nic as that has just become the defaco way to represent it (eveyone represents it this way) and what folks have become used to.

    And, the settigns are portable to the VM, not bound to the virutal switch.  So as the VM moves, the settings move with it.


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Friday, March 9, 2012 3:46 PM
  • THANK YOU, Brian. I got it.

    I really have not seen that. I dont know why. Maybe it's because I did not have the idea to look for it on the left hand side of the settings window. As we all know, if you are looking to desperately for it, you don't find anything.

    You saved my day,

    Thorsten

    Saturday, March 10, 2012 1:05 PM
  • What I miss is explanation how to make VM authorized to send DHCP respond? So if you turn on "DHCP guard" on VM's NIC you are protecting that VM from unauthorized DHCP's. Question is how to authorize a VM with legit DHCP???
    Tuesday, June 5, 2012 2:37 PM
  • By turning on DHCP guard you're protecting your LAN from that VM
    responding to a DHCP request, the VM itself would still get an address
    from a real DHCP server normally.
     

    Bob Comer - Microsoft MVP Virtual Machine
    Tuesday, June 5, 2012 2:59 PM
  • Actually, what happens is that the VM where DHCP guard is turned on cannot send a DHCP acknowlege if it received a broadcast request.

    I currently use this to test multiple DHCP servers on a test network.  I have multiple DHCP VMs all configured and working.

    When I want one oto work, I turn on DHCP Guard on all the ones that I don't want to respond to client requests.  Then the remaining one can respond (where DHCP Guard is not turned on).  And, I can have them all working.  I don't need to disable services, they can be joined tot he same domain, etc.

    Router Guard is similar.  It prevents the VM from broadcasting that it is a router / gateway and therefore not available to forward packets.

    Both of these are at the virtual port / NIC level.  So, if your VM is multi-homed you need to do the correct port.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Tuesday, June 5, 2012 3:08 PM
  • I understand now, you are actually protecting the network from the VM not the other way around. DHCP guard could be easily called Disable DHCP ACK or Disable DHCP offer.

    In that case I  think this should be enabled by default (forbid DHCP offer from all VM's) and if you are installing DHCP role on your VM you should disable the guard protection (Allow DHCP offer from that VM) don't you think?

    Tuesday, June 5, 2012 4:05 PM
  • I only think that you should enable it where appropriate. 

    For one, it causes some additional overhead on the virtual switch.

    If you had a bunch of infrastructure VMs with Windows Server and the like (or Linux for that matter) I would use this as appropriate.

    Would I enable it on 1000+ VDI desktops running Windows XP / 7 / 8?  Nope, why bother.  It also might interact strangely with the VMs getting DHCP addresses or other networking, no one knows at this point.

    I think thisis one of those features that needs a bit of smarts applied to it.  I see it really useful in safe-guarding, and in aiding in preventing problems in DR and recovery rehersals, and in test and development.  But I don't think it prudent to always turn it on.

    If it was prudent to always be on, MSFT would have it default to always on - that is how they roll.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Tuesday, June 5, 2012 4:14 PM
  • Makes sense.

    Thnx for replies guys.

    Tuesday, June 5, 2012 4:57 PM