locked
Network controller mandatory for SDN in 2016? RRS feed

  • Question

  • Hello.

    I'm designing my "next" virtualization environment for when 2016 drops. I'm really struggling to see where the network controller fits in.

    In my previous environment we used NVGRE Gateways and VMM for our network virtualization. We are a fairly small municipal shop. We run two interconnected data centers that are connect via dark fibre. Basically it looks like a single DC. We are going to heavily leverage Storage replica and stretch clustering in 2016.

    We host a few smaller municipalities and have done so just using NVGRE gateways. Clearly I need additional cluster(s) to host the controller as well?

    So other than controlling the NGRE Gateway somehow, what else do I get with the network controller if 2016 came out tomorrow? Assuming that my older physical gear is not compatible.

    1) Will I still be able to use 2016  Gateways without it?

    2) Will Azure "Stack" work without it?

    3) Can a controller be added in later on? Once our physical equipment can communicate with it?

    Thanks

    Monday, May 2, 2016 5:03 PM

Answers

  • Hello.

    I'm designing my "next" virtualization environment for when 2016 drops. I'm really struggling to see where the network controller fits in.

    In my previous environment we used NVGRE Gateways and VMM for our network virtualization. We are a fairly small municipal shop. We run two interconnected data centers that are connect via dark fibre. Basically it looks like a single DC. We are going to heavily leverage Storage replica and stretch clustering in 2016.

    We host a few smaller municipalities and have done so just using NVGRE gateways. Clearly I need additional cluster(s) to host the controller as well?

    So other than controlling the NGRE Gateway somehow, what else do I get with the network controller if 2016 came out tomorrow? Assuming that my older physical gear is not compatible.

    1) Will I still be able to use 2016  Gateways without it?

    2) Will Azure "Stack" work without it?

    3) Can a controller be added in later on? Once our physical equipment can communicate with it?

    Thanks

    Hi There,

    I've provided some replies based on testing that I've done with the technical preview:

    1) Will I still be able to use 2016  Gateways without it?

    Yes - I've tested this and the Gateway provider functions identically to the previous version.  Deploy the gateway and host clusters and use the connection strings as you have before.

    2) Will Azure "Stack" work without it?

    Based on what I've seen probably not.  It's in early preview but it relies heavily on the network controller and by extension network controller host agents and Azure Forwarding Extension to provide the control plane and forwarding smarts.  The control plane for Azure Pack and 2012 R2 is VMM and SPF.  Given that Azure Stack doesn't utilise VMM at all its unlikely that you'll be able to use it without the Network Controller role.

    3) Can a controller be added in later on? Once our physical equipment can communicate with it?

    I don't see why not, the Network Controller is rest based and, provided your switches and hardware are OMI compatible they should work fine.  That being said, your WIndows Server 2016 Hosts can be managed by them even if your hardware isn't.

    We host a few smaller municipalities and have done so just using NVGRE gateways. Clearly I need additional cluster(s) to host the controller as well?

    Not necessarily, the Network Controller itself does not require a dedicated host as its rest based, has application level clustering and doesn't do any actual network virtualization.  The network controller doesn't need to be connected to any of your virtualized networks either; just your infrastructure management network so it can manage the devices you decide to place within its scope.  I've heard conflicting reports surrounding the requirement of dedicated hosts for Gateway and SLB services and would love someone at MS to clarify this for us as the being able to host gateway, load balancer and network virtualized workloads across the same hosts would be awesome :)  The SLB MUX instances can be deployed independently of each other an the Network Controller(s) will automatically determine which instance will host the VIPs/DIPs for client connections and fail over if a single instance becomes available.  Given some of the more interesting VMM DB issues I've encountered from time to time and the requirement for an in-site cluster for VMM high availability I like the idea of decoupling the Network Orchestration and Control Plane from VMM.

    SDN NC Planning

    This is based purely on my testing so far, I hope that helps :)

    Cheers,

    Hayden


    Tuesday, May 3, 2016 12:12 PM

All replies

  • Hello.

    I'm designing my "next" virtualization environment for when 2016 drops. I'm really struggling to see where the network controller fits in.

    In my previous environment we used NVGRE Gateways and VMM for our network virtualization. We are a fairly small municipal shop. We run two interconnected data centers that are connect via dark fibre. Basically it looks like a single DC. We are going to heavily leverage Storage replica and stretch clustering in 2016.

    We host a few smaller municipalities and have done so just using NVGRE gateways. Clearly I need additional cluster(s) to host the controller as well?

    So other than controlling the NGRE Gateway somehow, what else do I get with the network controller if 2016 came out tomorrow? Assuming that my older physical gear is not compatible.

    1) Will I still be able to use 2016  Gateways without it?

    2) Will Azure "Stack" work without it?

    3) Can a controller be added in later on? Once our physical equipment can communicate with it?

    Thanks

    Hi There,

    I've provided some replies based on testing that I've done with the technical preview:

    1) Will I still be able to use 2016  Gateways without it?

    Yes - I've tested this and the Gateway provider functions identically to the previous version.  Deploy the gateway and host clusters and use the connection strings as you have before.

    2) Will Azure "Stack" work without it?

    Based on what I've seen probably not.  It's in early preview but it relies heavily on the network controller and by extension network controller host agents and Azure Forwarding Extension to provide the control plane and forwarding smarts.  The control plane for Azure Pack and 2012 R2 is VMM and SPF.  Given that Azure Stack doesn't utilise VMM at all its unlikely that you'll be able to use it without the Network Controller role.

    3) Can a controller be added in later on? Once our physical equipment can communicate with it?

    I don't see why not, the Network Controller is rest based and, provided your switches and hardware are OMI compatible they should work fine.  That being said, your WIndows Server 2016 Hosts can be managed by them even if your hardware isn't.

    We host a few smaller municipalities and have done so just using NVGRE gateways. Clearly I need additional cluster(s) to host the controller as well?

    Not necessarily, the Network Controller itself does not require a dedicated host as its rest based, has application level clustering and doesn't do any actual network virtualization.  The network controller doesn't need to be connected to any of your virtualized networks either; just your infrastructure management network so it can manage the devices you decide to place within its scope.  I've heard conflicting reports surrounding the requirement of dedicated hosts for Gateway and SLB services and would love someone at MS to clarify this for us as the being able to host gateway, load balancer and network virtualized workloads across the same hosts would be awesome :)  The SLB MUX instances can be deployed independently of each other an the Network Controller(s) will automatically determine which instance will host the VIPs/DIPs for client connections and fail over if a single instance becomes available.  Given some of the more interesting VMM DB issues I've encountered from time to time and the requirement for an in-site cluster for VMM high availability I like the idea of decoupling the Network Orchestration and Control Plane from VMM.

    SDN NC Planning

    This is based purely on my testing so far, I hope that helps :)

    Cheers,

    Hayden


    Tuesday, May 3, 2016 12:12 PM
  • Hello, if your intent is to use storage replica and stretch clustering across the two datacenters (which appear as one DC), could you clarify whether you need to use the SDN infrastructure? I'm simply looking to see if your infrastructure requirements can be simplified to better match what you are looking to do.

    Having said that, the network controller will allow you to create isolated VXLAN based virtual networks to run your workloads, perform L3/L4 load balancing, setup L4 firewall policies, control gateways (as you point out in your mail). This infrastructure is available in Windows Server 2016, and is the underpinning for the Microsoft Azure Stack. The new Azure inspired SDN stack in Windows Server 2016 is based on the network controller, and is manageable using SCVMM.

    In Windows Server 2012 R2, the control and management planes were fused together into SCVMM (this model is supported in WS2016 as well - that is, what you have deployed should continue to work in 2016). The SDN stack we bring in WS2016 is Azure inspired, and offers new capabilities (such as load balancing, smarter network segmentation for security, and so on).

    As Hayden correctly points out, there is a little bit of planning in an SDN deployment, which we'll be happy to work with you on. Just let us know. It would also be valuable to think through whether you require SDN in your deployment. Happy to talk about this.

    Thanks,

    Ravi

    • Proposed as answer by Hello_2018 Wednesday, May 4, 2016 7:33 AM
    Tuesday, May 3, 2016 5:06 PM
  • Hi Ravi,

    Is VXLAN now the default SDN encapsulation method in Server 2016 or is it still NVGRE?

    Cheers,

    Hayden

    Wednesday, May 4, 2016 12:28 AM
  • Hayden, short answer is Yes, VXLAN is the default.

    Long answer is that we have a new, Azure inspired, network controller based SDN stack in Windows Server 2016. We indeed are using VXLAN as the default encapsulation format for that. For the stack that we had in 2012 R2, we are retaining all defaults as is to ensure that any existing solutions work as is. Hopefully, this makes sense.

    Even longer answer: Most customers should not care whether we use VXLAN or NVGRE. Many customers are equating network virtualization with the underlying encapsulation format, whereas the format is simply a means to realizing the power of network virtualization. In Windows Server 2016, you can swap out NVGRE for VXLAN as the encapsulation format (and vice versa), without any loss in functionality surrounding virtual networking/network virtualization. In other words, we want all customers to think of the value they are hoping to glean from virtual networks (bring your own IP, overlapped addresses, agility to move workloads independent of the underlying physical network infrastructure, etc), and not worry as much about the encap format.

    Hope this helps :)

    Cheers,

    Ravi

    @ravirao_sdn

    • Proposed as answer by Hello_2018 Wednesday, May 4, 2016 7:33 AM
    Wednesday, May 4, 2016 2:52 AM
  • Ravi, Our internal network does not use network virtualization at the moment, mainly because of our network layout and it being a logical datacenter with physical redundancy.

    We do use it for our hosting of clients. I'm just trying to see what will change and make sure I'm built to grow.

    Thank-you for the information.  

    Wednesday, May 4, 2016 3:10 PM
  • Hayden, short answer is Yes, VXLAN is the default.

    Long answer is that we have a new, Azure inspired, network controller based SDN stack in Windows Server 2016. We indeed are using VXLAN as the default encapsulation format for that. For the stack that we had in 2012 R2, we are retaining all defaults as is to ensure that any existing solutions work as is. Hopefully, this makes sense.

    Even longer answer: Most customers should not care whether we use VXLAN or NVGRE. Many customers are equating network virtualization with the underlying encapsulation format, whereas the format is simply a means to realizing the power of network virtualization. In Windows Server 2016, you can swap out NVGRE for VXLAN as the encapsulation format (and vice versa), without any loss in functionality surrounding virtual networking/network virtualization. In other words, we want all customers to think of the value they are hoping to glean from virtual networks (bring your own IP, overlapped addresses, agility to move workloads independent of the underlying physical network infrastructure, etc), and not worry as much about the encap format.

    Hope this helps :)

    Cheers,

    Ravi

    @ravirao_sdn

    Thankyou for the short and longer answers, it definitely clarifies things for me :)

    When I first started testing the Server 2016 SDN stack with my existing gateway I was scratching my head as to why my existing Gateways hosts couldnt talk to the Virtual Machines.  I definitely agree with your statement that focusing on the benefits rather than the encapsulation method makes perfect sense.  If i we to make one suggestion, it is that the default encapsulation method is made very clear and some information on how to change it for those running mixed mode environments where Server 2012 R2 hosts and gateways are still in use.(i.e. Service Providers running Azure pack).  Another thing I get asked about alot at the moment is whether or not a dedicated edge host/cluster is required to host the SLB MUX and RAS Gateway roles.  My understading based on the Doco is that this is no longer the case but I've heard some differing reports depending on who I ask.

    Thanks again,

    Hayden

    Thursday, May 5, 2016 11:15 PM
  • @Peanican - just let us know if you have any further questions. We will be happy to clarify. If you have a hosting environment, then the use of SDN likely will be valuable. The value of SDN is that it attempts to make the underlying network capacity look like a pool that can be provisioned dynamically based on workload needs. Let us know if you want links to documentation or anything else.

    @Hayden - MUX's do not need dedicated hosts. We will make it clear in the docs that the default encap is VXLAN, and how it can be changed. We will also share with you the location where we are doing so that you can tell us if it is clear. At the same time, we expect that the R2 stack and the new Azure inspired stacks will be logically separate from each other, and if needed would be connected via gateways. For simplicity, I would recommend keeping workloads holistically in one stack or the other.

    Cheers,

    Ravi

    @ravirao_sdn

    Monday, May 9, 2016 3:58 PM
  • @Ravi -  If I setup a gateway the traditional way using vmm 2016 and server 2016 Preview5, is it using xvlan by default? My NICS (intel x520) claim to support xvlan acceleration. I see no settings on the physical NICs for this setting. To enable the xvlan offloading is there normally a physical setting within the NIC or is it just industry standard for it to work?

    Thanks.

    Monday, May 9, 2016 4:34 PM
  • Setting up a gateway in the way you describe will not use VXLAN, unless you are using the controller. That is, when you use the controller, it pushes down policy to the underlying hosts that VXLAN is the underlying encap is to be used.

    Regarding Intel x520, I don't think it supports VXLAN acceleration. Let me get back on this.

    Ravi

    @ravirao_sdn

    Monday, May 9, 2016 5:40 PM
  • I checked on the x520s with Don Stanwyck (who works with our NIC partners on offload support). The x520 does not support VXLAN offloads (implying the NIC cannot accelerate VXLAN traffic). It should support VXLAN traffic (without acceleration) of course.

    Thanks,

    Ravi

    @ravirao_sdn

    Monday, May 9, 2016 8:01 PM
  • Thanks for checking.

    One more question. I've played with the Azure Stack PoC and I know that there is no reliance on vmm.

    Will it still be possible to manage new gateways and the network controller in vmm and front them with azure stack? Kind of like a transition period.

    Tuesday, May 10, 2016 7:15 PM
  • You will be able to manage the network controller and gateways using VMM. In fact, you can do this right away in TP5!

    Azure Stack is a vertical stack from the portal on down. It really is a different concept, that of having an Azure region in your datacenter. I expect you'll need to move workloads one at a time to this environment.

    Thanks,

    Ravi

    @ravirao_sdn

    Wednesday, May 11, 2016 4:04 AM
  • Hi Ravi,

    You say that you can do with with TP5 but I am having a very difficult time getting this to work. I have configured the NC cluster and can deploy NC managed logical switches etc. but nothing can communicate. Not the host vNic or VMs connected to the switch. Unless something is missing from the documentation, this does not work. Is there some information on how to debug this stuff?

    Thanks

    Dean

    Wednesday, May 11, 2016 11:56 AM
  • Seeing the same thing as Dean.  No addresses are assigned to the virtual machines and I can't any traffic being sent from the Virtual Switches on any of the hosts with a VMSwitch managed by the network controller.  Here is the debug output from the Hyper-V-VfpExt from one of the Hyper-V hosts with the NC managed switch, Physical NIC and VM NIC associated with the switch.

    Thanks,

    Hayden

    Thursday, May 12, 2016 3:25 AM
  • I have done some more testing and found this link https://technet.microsoft.com/en-us/library/mt715794.aspx

    The vfpctrl utility is very interesting and I noticed two things:

    1. My Host Management vNic deployed with the Logical Switch was in a Blocked state

    2. Using the tcp-log, I can see the connection being made to that interface on the local port but nothing is being returned. Using the other troubleshooting I have found that the SCVMM Default ACL is being applied to this port:

    {
      "value": [
        {
          "resourceRef": "/accessControlLists/f8b97a4c-4419-481d-b757-a58483512640",
          "resourceId": "f8b97a4c-4419-481d-b757-a58483512640",
          "resourceMetadata": {
            "resourceName": "SCVMM Default ACL"
          },
          "etag": "W/\"0209196a-c5ac-41a7-abed-70ee5d56a3fd\"",
          "instanceId": "6a1db508-bc01-483c-97d5-e06a4cef3e05",
          "properties": {
            "provisioningState": "Succeeded",
            "aclRules": [
              {
                "resourceRef": "/accessControlLists/f8b97a4c-4419-481d-b757-a58483512640/aclRules/f8b97a4c-4419-481d-b757-a58483512640",
                "resourceId": "f8b97a4c-4419-481d-b757-a58483512640",
                "etag": "W/\"0209196a-c5ac-41a7-abed-70ee5d56a3fd\"",
                "instanceId": "5fa1b9ca-e31e-47f9-9f81-b03dbf42287a",
                "properties": {
                  "provisioningState": "Succeeded",
                  "protocol": "All",
                  "sourcePortRange": "*",
                  "destinationPortRange": "*",
                  "action": "Allow",
                  "sourceAddressPrefix": "*",
                  "destinationAddressPrefix": "*",
                  "priority": "65000",
                  "type": "Inbound",
                  "logging": "Enabled"
                }
              }
            ],
            "ipConfigurations": [
              {
                "resourceRef": "/networkInterfaces/edeb4236-9ea2-444f-905a-80be9095bb54/ipConfigurations/e0da8465-b350-4778-9e96-19f598703bdb"
              }
            ],
            "subnets": []
          }
        }
      ],
      "nextLink": ""
    }

    To me this looks like it is only allowing INBOUND traffic which actually is what I am seeing. If these ACL's behave anything like Azure NSG's there needs to be an OUTBOUND rule too that will allow it. I believe that these things are not stateful. I will add the rule and see if I can communicate.

    Dean

    Thursday, May 12, 2016 6:19 AM
  • Hello Dean and Hayden,

    Thanks for trying NC deployment with VMM.

    Did you guys try the deployment E2E using following guide or you deployed NC using Windows Server cmdlets and later on-boarded NC into VMM?

    https://technet.microsoft.com/library/mt695701(SC.16).aspx

    Currently VMM only supports managing NC based set up if the complete deployment is done using SCVMM guidance from the above link.

    In case you have used VMM for complete deployment and are still facing this issue, please share the VMM traces from your env so that we can take a closer look?

    Tuesday, May 17, 2016 10:19 AM
  • I would love to say "yes" but I did not. I do not have access to 4 servers in my lab and did not use the service template to deploy the NC, it is not that difficult. I have a lot of knowledge around HNV1 and understand all the concepts on HNV2. Please let me know where exactly you want me to trace, VMM, HOST, NC, etc. and I will gather anything you need. I am using VMMTrace 2.0 unless you have something else. I am happy to take private e-mail for upload locations etc.

    Dean

    Tuesday, May 17, 2016 10:30 AM
  • I would love to say "yes" but I did not. I do not have access to 4 servers in my lab and did not use the service template to deploy the NC, it is not that difficult. I have a lot of knowledge around HNV1 and understand all the concepts on HNV2. Please let me know where exactly you want me to trace, VMM, HOST, NC, etc. and I will gather anything you need. I am using VMMTrace 2.0 unless you have something else. I am happy to take private e-mail for upload locations etc.

    Dean

    Hi Manish and Dean,

    I followed the guide but used a single standalone network controller as a opposed to the production 3 node template.  (I too have lab hardware constraints.)  Happy to provide traces from my environment as well if you need them for cross referencing.

    Hayden

    Wednesday, May 18, 2016 2:26 AM
  • Hi Manish,

    I have reviewed the Service Deployment scripts from the NC deployment process using SCVMM and I can confirm that I have used the exact same commands to configure my NC cluster. In addition, all queries and tests conducted against the NC cluster indicate that it is working as expected. The host, host networks adapters and logical networks etc. are all registered and unregistered with the NC when they are manipulated in SCVMM.

    Secondly, I have run through the steps in the URL provided and if you follow the steps, followed by the deployment of the SET enabled switch, then these instructions do not work. The deployment of the SET switch cannot use a NON- NC managed Logical Network and you cannot create overlapping logical networks. I will try again with a temporary management logical network before creating the NC manage management logical network but I just want to call out that the instructions do not work.

    Please can you provide the required tracing information so that we can debug this, once I have reconfigured the network?

    Dean

    Wednesday, May 18, 2016 8:34 PM
  • Hi Manish and Ravi,

    I know that I have not followed the guide exactly but here is some more info. This is what I have done, post NC Cluster deployment, using SCVMM:

    1. Created NC Controlled Logical Network called Management and Assigned VLAN 50 (10.10.50.0/24)
    2. Created IP Address Pool 10.10.50.4 - 254
    3. Created NC Controlled Logical Switch
    4. Created Uplink Port Profile with Management network site
    5. Deployed Logical Switch to HV Host on uplink nic
    6. Deployed Virtual Network Adapter with 10.10.50.30 IP address

    Issue:

    1. Network Controller has all the following:

        Hyper-V Host
        Hyper-V Host Network Interface
        Logical Network
        Logical Network Subnet

    2. Debug-NetworkControllerConfigurationState -NcIpAddress hnnccluster.mydomain.com
    ---------------------------------------------------------------------------------------------------------
    ResourcePath:     https://hnnccluster.mydomain.com/Networking/v1/servers/03d40274-0435-051d-9f06-750700080009
    Status:           hnhost03.mydomain.com
    Status:           Warning
     
    Source:           SoftwareLoadBalancerManager
    Code:             HostNotConnectedToController
    Message:          Host is not Connected.
    ----------------------------------------------------------------------------------------------------------

    Troubleshooting indicates

    1. Verify basic IP connectivity over management network using ping - Tick
    2. Query Network Controller for Configuration State of Server resource(s) using Debug-NetworkControllerConfigurationState - Tick
    3. Check socket connections - Tick (Host is connecting on port TCP6640)
    4. Check Check SouthBound channel Certificates on Hyper-V Host - Tick

    Error message means:

    HostNotConnectedToController - The Host is not yet connected to the Network Controller.    
    Port Profile not applied on the host or the host is not reachable from the Network Controller.
    Validate that HostID registry key (under HKLM/System/CurrentControlSet/Services/NcHostAgent/Parameters) matches the
    Instance ID of the server resource in question (Get-NCServer | convertto-json -depth 8)

    I have validated the Host ID as instructed.

    What else can I do to get the Port Profile assigned?

    PS C:\> Get-NetworkControllerServer -ConnectionUri https://hnnccluster.mydomain.com | convertto-json -depth 8
    {
        "Tags":  null,
        "ResourceRef":  "/servers/03d40274-0435-051d-9f06-750700080009",
        "InstanceId":  "387b9aeb-ceec-46d7-9890-704995493be7",
        "Etag":  "W/\"01adef66-31d2-4681-b5b5-32a234981816\"",
        "ResourceMetadata":  {
                                 "Client":  null,
                                 "TenantId":  null,
                                 "GroupId":  null,
                                 "ResourceName":  "hnhost03.mydomain.com",
                                 "OriginalHref":  null
                             },
        "ResourceId":  "03d40274-0435-051d-9f06-750700080009",
        "Properties":  {
                           "Certificate":  null,
                           "RackSlot":  null,
                           "OS":  null,
                           "Model":  null,
                           "Vendor":  null,
                           "Serial":  null,
                           "ConfigurationState":  {
                                                      "Status":  "Warning",
                                                      "DetailedInfo":  [
                                                                           {
                                                                               "Source":  "SoftwareLoadBalancerManager",
                                                                               "Message":  "Host is not Connected.",
                                                                               "Code":  "HostNotConnectedToController"
                                                                           }
                                                                       ],
                                                      "LastUpdatedTime":  "\/Date(1464089491928)\/"
                                                  },
                           "ProvisioningState":  "Succeeded",
                           "Health":  {
                                          "TimeSinceLastPollInSeconds":  0,
                                          "Health":  "Unmonitored"
                                      },
                           "Usages":  null,
                           "Connections":  [
                                               {
                                                   "ManagementAddresses":  [
                                                                               "hnhost03.mydomain.com"
                                                                           ],
                                                   "CredentialType":  "usernamePassword",
                                                   "Protocol":  null,
                                                   "Port":  null,
                                                   "Credential":  {
                                                                      "Tags":  null,
                                                                      "ResourceRef":  "/credentials/6e637eac-51d4-44ba-ad15-3f3e9b1ef46f",
                                                                      "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                      "Etag":  null,
                                                                      "ResourceMetadata":  null,
                                                                      "ResourceId":  null,
                                                                      "Properties":  null
                                                                  }
                                               },
                                               {
                                                   "ManagementAddresses":  [
                                                                               "hnhost03.mydomain.com"
                                                                           ],
                                                   "CredentialType":  "X509Certificate",
                                                   "Protocol":  null,
                                                   "Port":  null,
                                                   "Credential":  {
                                                                      "Tags":  null,
                                                                      "ResourceRef":  "/credentials/41229069-85d4-4352-be85-034d0c5f4658",
                                                                      "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                      "Etag":  null,
                                                                      "ResourceMetadata":  null,
                                                                      "ResourceId":  null,
                                                                      "Properties":  null
                                                                  }
                                               }
                                           ],
                           "MonitoredGroup":  null,
                           "TopologyNode":  {
                                                "Tags":  null,
                                                "ResourceRef":  "/topologies/desiredStateTopology/topologyNodes/387b9aeb-ceec-46d7-9890-704995493be7",
                                                "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                "Etag":  null,
                                                "ResourceMetadata":  null,
                                                "ResourceId":  null,
                                                "Properties":  null
                                            },
                           "NetworkInterfaces":  [
                                                     {
                                                         "ResourceMetadata":  null,
                                                         "ResourceRef":  "/servers/03d40274-0435-051d-9f06-750700080009/networkInterfaces/Port 4",
                                                         "InstanceId":  "3103dcfd-ce9d-4180-8b9c-33bc61108250",
                                                         "Etag":  "W/\"01adef66-31d2-4681-b5b5-32a234981816\"",
                                                         "ResourceId":  "Port 4",
                                                         "Properties":  {
                                                                            "InterfaceName":  null,
                                                                            "Mac":  null,
                                                                            "IPConfiguration":  null,
                                                                            "VlanIds":  null,
                                                                            "AdminStatus":  null,
                                                                            "OperationalStatus":  null,
                                                                            "InterfaceIndex":  null,
                                                                            "InterfaceSpeed":  null,
                                                                            "Health":  {
                                                                                           "TimeSinceLastPollInSeconds":  0,
                                                                                           "Health":  "Unmonitored",
                                                                                           "AvailabilityAlerts":  null,
                                                                                           "PerformanceAlerts":  null,
                                                                                           "ConfigurationAlerts":  null,
                                                                                           "SecurityAlerts":  null,
                                                                                           "UnmonitoredHealthParameters":  null,
                                                                                           "UnknownHealthParameters":  null
                                                                                       },
                                                                            "IsBMC":  "false",
                                                                            "Usages":  null,
                                                                            "ProvisioningState":  "Succeeded",
                                                                            "LogicalSubnets":  [
                                                                                                   {
                                                                                                       "ResourceMetadata":  null,
                                                                                                       "ResourceRef":  "/logicalnetworks/67a5bb93-9ff8-4c3b-9a41-1a346852e366/subnets/41d79170-785a-4002-95e3-6a68aa78cc7d",
                                                                                                       "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                                                       "Etag":  null,
                                                                                                       "ResourceId":  null,
                                                                                                       "Properties":  null
                                                                                                   }
                                                                                               ],
                                                                            "VirtualSwitch":  null,
                                                                            "TerminationPoint":  {
                                                                                                     "ResourceMetadata":  null,
                                                                                                     "ResourceRef":  "/topologies/desiredStateTopology/topologyNodes/387b9aeb-ceec-46d7-9890-704995493be7/terminationPoints/3103dcfd-ce9d-4180-8b9c-33bc61108250",
                                                                                                     "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                                                     "Etag":  null,
                                                                                                     "ResourceId":  null,
                                                                                                     "Properties":  null
                                                                                                 }
                                                                        }
                                                     }
                                                 ]
                       }
    }
    There is no connectivity to the management IP assigned. I am not sure where I have gone wrong but this is just not working for me.


    Tuesday, May 24, 2016 11:49 AM
  • Interesting.

    As a quick validation, could you confirm whether the connection string on NC looks like below (esp the last Service name part):

    serverurl=https://10.184.109.69;SouthBoundIPAddress=10.184.109.69;servicename=NC_VMM_TP5

    in cases where NC is deployed OOB, mostly servicename string is not appended in the connection string and this leads to the issues you are facing.

    if it's not the case, we can take a look at the logs (VMM Trace 2.0 is good) and continue this conversation over email. 

    Tuesday, May 24, 2016 2:28 PM
  • The VMM NC connection string is this:

    serverurl=https://hnnccluster.mydomain.dom;SouthBoundIPAddress=10.10.50.25

    You are correct that there is no servicename value as it would not let me set one, the NC was not deployed using it.Is there something we can do to work around this? What does the servicename have to do with the management of the service? If you say that this can lead to this problem then this may be it. It does not make sense but...

    Something further to note is that the Logical Switch is Complaint but the Virtual Network adapter is showing Non-compliant with the following:

    Warning (26856)
    The primary VLAN ID '0' and the secondary VLAN ID '0' for the virtual network adapter are incompatible with the VM network 'Management'.

    When I try to remediate the adapter, I get the following error:

    Error (25270)
    No MAC addresses were available to allocate to network adapter 'Management'.
    Recommended Action
    Allocate additional MAC address pools and retry the operation.

    I am happy to trace. I just need to know what you want me to capture. Which specific action you want me to capture.

    EDIT:

    I can make this Virtual Network Adapter compliant by issuing the following PowerShell command (I still cannot communicate with it though):

    Get-VMNetworkAdapter -ManagementOS -Name "Management" | Set-VMNetworkAdapterVlan -Access -VlanId 50

    The original state of the adapter was:

    Get-VMNetworkAdapter -ManagementOS -Name "Management" | Get-VMNetworkAdapterVlan

    VMName VMNetworkAdapterName Mode     VlanList
    ------ -------------------- ----     --------
           Management           Untagged


    Tuesday, May 24, 2016 8:41 PM
  • The answer to your question can be best provided from the angle of supportability.

    Our focus with VMM 2016 TP5 is to deliver a reliable SDN deployment experience 'using' VMM. I acknowledge the need of being more flexible and providing capability to manage SDN VMs that are deployed outside VMM, and that's something we are working on too. But unfortunately, with TP5, you will need to redeploy the NC using VMM as described in our deployment guides below:

    https://technet.microsoft.com/library/mt695701%28SC.16%29.aspx?f=255&MSPPError=-2147217396

    Please let me know if you run into any issue following the guides. 

    Thanks,

    Manish

    Friday, May 27, 2016 9:15 AM
  • Hi,

    One step ahead of you. I have redeployed the network controller cluster using SCVMM service template and I can confirm that it is doing exactly the same thing! All registered and SCVMM is using it but still the same:

    Debug-NewNetworkControllerConfigurationState –NcIpAddress hnnccluster.mynetwork.com
    ---------------------------------------------------------------------------------------------------------
    ResourcePath:     https://hnnccluster.mynetwork.com/Networking/v1/servers/03d40274-0435-051d-9f06-750700080009
    Status:           hnhost03.mynetwork.com
    Status:           Warning
     
    Source:           SoftwareLoadBalancerManager
    Code:             HostNotConnectedToController
    Message:          Host is not Connected.
    ----------------------------------------------------------------------------------------------------------

    Network adapter still shows non-compliant and no network communication. The host NetworkController-NcHostAgent event log has the following logged, Event 604 (This was in the original NC deployment too):

    The following information was included with the event:
    Intel(R) 82579LM Gigabit Network Connection
    160
    The locale specific resource for the desired message is not present

    According to the documentation this is EncapOverheadNotSupported which is not a requirement but as per the documentation I have enabled and tested Jumbo Frames to get around this.

    Basically, this is performing EXACTLY has my original deployment. The same symptoms and zero communication with the deployed virtual network adapter. Here is the json again,

    Get-NetworkControllerServer -ConnectionUri https://hnnccluster.mynetwork.dom | convertto-json -depth 8
    {
        "Tags":  null,
        "ResourceRef":  "/servers/03d40274-0435-051d-9f06-750700080009",
        "InstanceId":  "f7a60e55-8300-4a06-8938-4719277549c0",
        "Etag":  "W/\"29a5cd46-8b45-42cc-8dee-8020b42d1542\"",
        "ResourceMetadata":  {
                                 "Client":  null,
                                 "TenantId":  null,
                                 "GroupId":  null,
                                 "ResourceName":  "hnhost03.mynetwork.dom",
                                 "OriginalHref":  null
                             },
        "ResourceId":  "03d40274-0435-051d-9f06-750700080009",
        "Properties":  {
                           "Certificate":  "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpYQUFBQUFFQUFBQUVBQUFBQUJBQUFBOEFBQUFCQUFBQUZBQUFBRFdtN2ZRSGQ5R2ZxYnh3bmU2TmtRaDh1aDVEDQpDd0FBQUFFQUFBQn
    NBQUFBVXdCREFGWUFUUUJOQUY4QVF3QkZBRklBVkFCSkFFWUFTUUJEQUVFQVZBQkZBRjhBDQpTd0JGQUZrQVh3QkRBRThBVGdCVUFFRUFTUUJPQUVVQVVnQklBRTRBU0FCUEFGTUFWQUF3QURNQUxnQm9BRzhBDQpiUUJsQUc0QVpRQjBBR0VB
    ZFFBdUFHUUFid0J0QUFBQUZBQUFBQUVBQUFBVUFBQUE0eGgyMjFGN1VVM3o5angxDQpGWlk5bEdQYmhnQURBQUFBQVFBQUFCUUFBQUJWWUFpa3d4TXNaUS96RzBSRFplejhqTVhRbkFJQUFBQUJBQUFBDQozQUFBQUJ3QUFBQ01BQUFBQVFBQU
    FDQUFBQUFBQUFBQUFBQUFBQUVBQUFCVEFFTUFWZ0JOQUUwQVh3QkRBRVVBDQpVZ0JVQUVrQVJnQkpBRU1BUVFCVUFFVUFYd0JMQUVVQVdRQmZBRU1BVHdCT0FGUUFRUUJKQUU0QVJRQlNBRWdBDQpUZ0JJQUU4QVV3QlVBREFBTXdBdUFHZ0Fi
    d0J0QUdVQWJnQmxBSFFBWVFCMUFDNEFaQUJ2QUcwQUFBQUFBQUFBDQpUUUJwQUdNQWNnQnZBSE1BYndCbUFIUUFJQUJUQUhRQWNnQnZBRzRBWndBZ0FFTUFjZ0I1QUhBQWRBQnZBR2NBDQpjZ0JoQUhBQWFBQnBBR01BSUFCUUFISUFid0IyQU
    drQVpBQmxBSElBQUFBRUFBQUFBUUFBQUJBQUFBQXJCZGRHDQo3b1pYd1Y3TGhFbUo4YnlmR1FBQUFBRUFBQUFRQUFBQTJGQXpUdXRPL2JkRUFaK2h4WUJBRjFrQUFBQUJBQUFBDQpFZ0FBQUZJQVV3QkJBQzhBVXdCSUFFRUFNUUFBQUNBQUFB
    QUJBQUFBQlFVQUFEQ0NCUUV3Z2dMcG9BTUNBUUlDDQpFR1FtTmVGUTRuU3hRZEgydXFLS0c2WXdEUVlKS29aSWh2Y05BUUVGQlFBd0lURWZNQjBHQTFVRUF4TVdTRTVJDQpUMU5VTURNdWFHOXRaVzVsZEdGMUxtUnZiVEFlRncweE5qQTFNRG
    d4TURFek16ZGFGdzB5TVRBeE1ERXhNREV6DQpNemRhTUNFeEh6QWRCZ05WQkFNVEZraE9TRTlUVkRBekxtaHZiV1Z1WlhSaGRTNWtiMjB3Z2dJaU1BMEdDU3FHDQpTSWIzRFFFQkFRVUFBNElDRHdBd2dnSUtBb0lDQVFDeDkrZEo3ekJyWFhm
    RlBoaytYeWhkSkU5Z0dhUTRITmxPDQpQN1lrUWFDWkJad0w0N0xwdzJ4NFljU3Q2dUNHK09wU041bjVHcVF4S3pEaEhKdzkrakNCTWkvMHN5bGRNd053DQprbi9ycDcxQzBVUU9jVjBYM2hIUW5OSEZoT3h4MEtpeFBRdU90aStvOWx1c2k2b3
    c5djN1ZUJydDVGanNBSGpEDQo3VXNPek5rdTB4REc2RElnOTNvSU1VMW9nWmlWdWw2eDc2Y2JlTXliSzRPSTNrS2FwajBLZ1JudnN4YjBJU2lDDQowUERhakQza2dNYXB6MXdvR2NsL3YvditsRTBVeTE4elJKUTg4ak9UZ3NzdkZVQmdTK2kw
    S0VobDhFS1Z6U3NNDQo3VnR5eGVJRTY1R2ZMWi9lWDAwK2ROT1BSTGJtSW5wZjY5cGlvUXBwM2lIUXNGNXNBRFpIM2FmanhFR1VJVUp5DQpkb0pHbkZIN2pXSHF2UTA0RTRnOHpPOUZUSXNYUUJQbmhSNGFUMGo5MVZMc083cVlFZGNhTnYvUj
    B1WDd0RzdVDQpLS2R0K1pGc2h6NjF4V0NoRlQ5OGQvcGdnRWs5Sng1WXAzYzFMSmYrREVZaEJCK0JKdHJPc0RnOHIwaGpCRlRIDQpySFVQS1RoV0ZXRVVHdGY5MWhocFR4dmpZbHZKNGhqZjk2bFNKMlhsMkZZd3VJWFlXK2R3K3J6b2dMWnBw
    ME1XDQpTM3p0N0hFMjVIQnFCc0VBMGpiczg3cnlBRmxBNTNsWkVvTEUwWjFIUU1SeGtGNGdTNnR5UnF0cHNlQTE1RkJMDQpYckFtTkQzZEdxUGZURDNHWW1SWXBaSUdPa3BvaVYwc2FIbFBHUWQ5d1k5dDdBa0FrMHNNSXRGNGJ5SEpseGxZDQ
    p2VFRpQjYvbWJ3SURBUUFCb3pVd016QWdCZ05WSFNVQkFmOEVGakFVQmdnckJnRUZCUWNEQVFZSUt3WUJCUVVIDQpBd0l3RHdZRFZSMFRBUUgvQkFVd0F3SUJBVEFOQmdrcWhraUc5dzBCQVFVRkFBT0NBZ0VBRmdoSVU5Zng3ME5UDQpwRzM1
    YXAvV0Z4K0UzU0NkT0V3MDFoZVd6ekFTSUFJV2loYisvVzdlVVZmUVlsc2FtK0NHRmFrU1hpck1YS21oDQpHYTJReG1ZOHlrQXRNRlhKK0F0Slo2REUzNy9Xd2xQRHpkMkpaYUxxcE9PMHRXanpBUHVaeEZ0enhWOWpCQkJsDQoyd2VpeFVZRn
    FQS3JJWHB0WlkxNVFLY2MvL3hGZHB5RDMrK242ZG5hb2lBK2Y0bisva3lZVG1IY0drN1hRa055DQp3ZlFVYkxtYTdwZ1U5Q2dISTFlMDFYOUxDMnpqYk1UcndRLzNjMlBEdmF3V2trUGV0L0NicE5KTjlzdURLVlRYDQpHWlV1Z01raHFFNnlk
    V1ZHQXgwMGFzVzVQVzB4L05CY0pXU21CSDNIWFpQUUZPcUNvb3c1WnhjVWx4UFZZaGtRDQpIdERleTZHa1RMR1FWcVBJQ01idVZLNWF2K3ZPWFFTdDg3dHF1UkFYVXU0Um9QV2NQUXVOeWtRQ1NEb3hIK3FEDQpsdlJnVExLQW1QeGxTRWlBc2
    ZtWkVXRWN4NXEvdmkyUkZIZ2dUaUxEc3RlS2hUMU9zRTlwelZ1emc0QUZkbi9rDQp4clFnTnZEeGxiNGsyU2V2SGlRcVVSWk9YMTRUZDJVQ2RhaU1jTFdiK2hXVXNlWnFWbnM5SFlmWm5tL3JtY1VJDQptSE52bVAzbVh2YmkyOGZOcWdrWFZ5
    SWVBTURsQ0ZsY1NwdEVpN1A3ekhqVWRIR1ZGanhCNDBha0ppaHF5T3YvDQpqMEVUWFYvWHZoNUlmYnFCNDBqbmQ1SXJBeHZYZ0NVKzFZb05MWWJ6SUFtWHVQNTBEVE90NHlOSW5VVVh2R01PDQpKT1F3RnJtdmVOZHhETVZIbVdoYU15L2RlZH
    dQcXFVPQ0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ0K",
                           "RackSlot":  null,
                           "OS":  null,
                           "Model":  null,
                           "Vendor":  null,
                           "Serial":  null,
                           "ConfigurationState":  {
                                                      "Status":  "Warning",
                                                      "DetailedInfo":  [
                                                                           {
                                                                               "Source":  "SoftwareLoadBalancerManager",
                                                                               "Message":  "Host is not Connected.",
                                                                               "Code":  "HostNotConnectedToController"
                                                                           }
                                                                       ],
                                                      "LastUpdatedTime":  "\/Date(1464345157465)\/"
                                                  },
                           "ProvisioningState":  "Succeeded",
                           "Health":  {
                                          "TimeSinceLastPollInSeconds":  640,
                                          "Health":  "Healthy"
                                      },
                           "Usages":  [
                                          {
                                              "Name":  {
                                                           "Value":  "timeSinceLastPoll",
                                                           "LocalizedValue":  "timeSinceLastPoll"
                                                       },
                                              "Unit":  "Seconds",
                                              "Context":  null,
                                              "CurrentValue":  664
                                          }
                                      ],
                           "Connections":  [
                                               {
                                                   "ManagementAddresses":  [
                                                                               "hnhost03.mynetwork.dom"
                                                                           ],
                                                   "CredentialType":  "usernamePassword",
                                                   "Protocol":  null,
                                                   "Port":  null,
                                                   "Credential":  {
                                                                      "Tags":  null,
                                                                      "ResourceRef":  "/credentials/6e637eac-51d4-44ba-ad15-3f3e9b1ef46f",
                                                                      "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                      "Etag":  null,
                                                                      "ResourceMetadata":  null,
                                                                      "ResourceId":  null,
                                                                      "Properties":  null
                                                                  }
                                               },
                                               {
                                                   "ManagementAddresses":  [
                                                                               "hnhost03.mynetwork.dom"
                                                                           ],
                                                   "CredentialType":  "X509Certificate",
                                                   "Protocol":  null,
                                                   "Port":  null,
                                                   "Credential":  {
                                                                      "Tags":  null,
                                                                      "ResourceRef":  "/credentials/41229069-85d4-4352-be85-034d0c5f4658",
                                                                      "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                      "Etag":  null,
                                                                      "ResourceMetadata":  null,
                                                                      "ResourceId":  null,
                                                                      "Properties":  null
                                                                  }
                                               }
                                           ],
                           "MonitoredGroup":  null,
                           "TopologyNode":  {
                                                "Tags":  null,
                                                "ResourceRef":  "/topologies/desiredStateTopology/topologyNodes/f7a60e55-8300-4a06-8938-4719277549c0",
                                                "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                "Etag":  null,
                                                "ResourceMetadata":  null,
                                                "ResourceId":  null,
                                                "Properties":  null
                                            },
                           "NetworkInterfaces":  [
                                                     {
                                                         "ResourceMetadata":  null,
                                                         "ResourceRef":  "/servers/03d40274-0435-051d-9f06-750700080009/networkInterfaces/Port 4",
                                                         "InstanceId":  "59c0b8b8-e1fa-4606-8f49-77bec25e5032",
                                                         "Etag":  "W/\"29a5cd46-8b45-42cc-8dee-8020b42d1542\"",
                                                         "ResourceId":  "Port 4",
                                                         "Properties":  {
                                                                            "InterfaceName":  null,
                                                                            "Mac":  null,
                                                                            "IPConfiguration":  null,
                                                                            "VlanIds":  null,
                                                                            "AdminStatus":  null,
                                                                            "OperationalStatus":  null,
                                                                            "InterfaceIndex":  null,
                                                                            "InterfaceSpeed":  null,
                                                                            "Health":  {
                                                                                           "TimeSinceLastPollInSeconds":  0,
                                                                                           "Health":  "Unmonitored",
                                                                                           "AvailabilityAlerts":  null,
                                                                                           "PerformanceAlerts":  null,
                                                                                           "ConfigurationAlerts":  null,
                                                                                           "SecurityAlerts":  null,
                                                                                           "UnmonitoredHealthParameters":  null,
                                                                                           "UnknownHealthParameters":  null
                                                                                       },
                                                                            "IsBMC":  "false",
                                                                            "Usages":  null,
                                                                            "ProvisioningState":  "Succeeded",
                                                                            "LogicalSubnets":  [
                                                                                                   {
                                                                                                       "ResourceMetadata":  null,
                                                                                                       "ResourceRef":  "/logicalnetworks/e32f1732-b47a-4d9f-a773-ad0353bdd26d/subnets/84cdf86d-0a77-4f5c-8aec-b1ee6c4ce5dd",
                                                                                                       "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                                                       "Etag":  null,
                                                                                                       "ResourceId":  null,
                                                                                                       "Properties":  null
                                                                                                   }
                                                                                               ],
                                                                            "VirtualSwitch":  null,
                                                                            "TerminationPoint":  {
                                                                                                     "ResourceMetadata":  null,
                                                                                                     "ResourceRef":  "/topologies/desiredStateTopology/topologyNodes/f7a60e55-8300-4a06-8938-4719277549c0/terminationPoints/59c0b8b8-e1fa-4606-8f49-77bec25e5032",
                                                                                                     "InstanceId":  "00000000-0000-0000-0000-000000000000",
                                                                                                     "Etag":  null,
                                                                                                     "ResourceId":  null,
                                                                                                     "Properties":  null
                                                                                                 }
                                                                        }
                                                     }
                                                 ]
                       }
    }
    It is not difficult to deploy an NC cluster. The scripts are VERY easy to follow so I believe that my build and this service deployment are 100% identical. On that, neat trick to name the cluster after the certificate subject name. Nice!

    Please let me know where I can trace. Perhaps this is just not working or something wrong with my hardware.

    Friday, May 27, 2016 10:36 AM
  • Hi All,
    Same behaviour on my side as well - no SLBM Connection to host no matter which way I deploy the network controller.
    Tuesday, May 31, 2016 5:39 AM
  • Hi folks - this error is somewhat misleading as it assumes the Software Load Balancer is already deployed. If you have not deployed the SLB Service Template through SCVMM yet (or through SDNExpress scripts) you can safely ignore this error.

    What it basically says is that the SLB Host Agent service running on a particular Hyper-V Host (server) cannot reach the Network Controller's SLB Manager service. Most likely cause for this is that the SLB Host Agent service is not running (nor should it be until SLB muxes have been deployed). 

    We will be suppressing this error for RTM in the case where SLB mux is not deployed yet. 

    Are your tenant VMs able to communicate with each other? Can you verify that Hyper-V hosts running tenant VMs have received policy from the Network Controller?

    C:\> ovsdb-client.exe dump tcp:127.0.0.1:6641 ms_vtep (ucast_macs_remote table should have entries in it)

    Also, NC Host Agent should have three established connections to the Network Controller

    C:\> netstat -aonp tcp |findstr 6640

    Lastly, additional info can be found for SDN troubleshooting here: https://technet.microsoft.com/en-us/library/mt715794.aspx

    Thursday, June 9, 2016 6:38 PM
  • Hi,

    Thanks for getting back to me. Just for the record, I have not got as far as getting a VM onto the switch yet. All that I have done is create a SET Switch, managed by network controllers, and a managementos Management interface. This interface itself is not able to communicate through the switch. As this vNic is basically the same thing as a VM network adapter, I would expect that VM would not be able to communicate either.

    Here is the result of the ovsdb-client query:

    Physical_Port table
    _uuid                                description                            name                                     status                                                                                                                                       
                                                                                                                                                             vlan_bindings vlan_stats
    ------------------------------------ -------------------------------------- ---------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------
    -------------------------------------------------------------------------------------------------------------------------------------------------------- ------------- ----------
    72c23ffe-af38-4189-bf45-825a04f4c427 "CD0B5D98-6675-40B5-BEDE-31AB428CD29A" "{0ef191dd-f14f-499f-98f0-39d0adf3ec26}" {vm_nic_interface_name=Management, vm_nic_lm_state="", vm_nic_macaddress="00-1D-D8-B7-1C-0A", vm_nic_port_id="CD0B5D98-6675-40B5-BEDE-31AB428
    CD29A", vm_nic_port_name=Management, vm_nic_switch_id="5F1F7FBD-A726-47CD-AE63-95E76DFB8ED6", vm_nic_switch_name="", vm_nic_vm_id="", vm_nic_vm_name=""} {}            {}        
    
    Physical_Switch table
    _uuid                                description distributed_router_mac management_ips name                                                                         ports                                  tunnel_ips
    ------------------------------------ ----------- ---------------------- -------------- ---------------------------------------------------------------------------- -------------------------------------- ----------
    0dca8206-be64-4e7e-9c4f-227b36ff664d ""          ""                     []             "387b9aeb-ceec-46d7-9890-704995493be7\\5f1f7fbd-a726-47cd-ae63-95e76dfb8ed6" [72c23ffe-af38-4189-bf45-825a04f4c427] []        
    
    

    Here is the result of the Net Stat

    PS C:\WINDOWS\system32> netstat -aonp tcp |findstr 6640
      TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING       1800
      TCP    192.168.10.206:64607   10.10.50.80:6640       TIME_WAIT       0
      TCP    192.168.10.206:64608   10.10.50.80:6640       TIME_WAIT       0
      TCP    192.168.10.206:64624   10.10.50.80:6640       TIME_WAIT       0

    The IP address 192.168.10.206 is the temporary IP assigned to the host. I have deployed the management network adapter as 10.10.50.100, which is on the same subnet as the NC cluster, 10.10.50.80. There is ZERO traffic allowed across this managementos vNic.

    I have referred to the debugging link you have provided in an earlier post of mine.

    Friday, June 10, 2016 12:40 AM
  • Hi,

    I have tried various permutations of this deployment and cannot get it to work. Any other tips? I have now deployed VMs and they have the following error is SCVMM:

    Warning (26909)
    The virtual subnet Id '0' configured on the virtual network adapter is incompatible with the VMSubnet 'Subnet 1' configured on the adapter .

    Recommended Action
    Remediate the compliance of this virtual network adapter by specifying a different VM network if necessary.

    Remediation does nothing to assist this.

    Dean

    Wednesday, June 22, 2016 8:39 PM
  • Hello,

    I followed also the guide to setup a standalone NC and have trouble figuring the servicename for the connection string in SCVMM. (https://technet.microsoft.com/en-us/system-center-docs/vmm/scenario/sdn-network-controller).

     

    In single node deployment, ServerURL should be the network controller FQDN and, servicename must be the network controller service instance name. Example: serverurl=https://NCCluster.contoso.com;servicename=NC_VMM_RTM "

    I tried to use the hostname, fqdn, ip address but get the same error when adding Network Service in SCVMM:

    "Error (50173)
    Error (50173)
    Failed to locate a unique active service instance by the name of 'one of the above' which provides Windows Server Network Controller.

    Recommended Action
    Ensure service template for Network Controller is deployed properly and has a unique name."

    Many thanks for helping me with this...

     



    Thomas.

    Wednesday, May 3, 2017 2:32 PM
  • Hi,

    I found that a previously deleted SCService had the same name and caused this error. You can find it by using:

    Get-SCService

    Find the ID of the duplicate SC Service, then use Get-SCService -ID XXXX..XXX | Remove-SCService

    Interestingly, once I fixed that, I then got a different error with [NoParam] with the same error code 50173.

    Let me know if you have any luck as I'm backing my head against a brick wall.

    jas :)

    Friday, May 12, 2017 4:06 AM