For a while now I’ve been using the Netsh SkipAsSource Flag to allow multiple IPs on a server and only the primary IP registers in DNS. The previous series of articles in this series are here:
Update 19-9-2013; Tried this out on the RTM build of Windows Server 2012 R2. Same issue.
Life was good until Shawn Martin added a comment asking about a hotfix for Windows Server 2012 to fix a previous issue from Windows Server 2008 R2. Hotfix 2554859 was noted in the original article, but I had not experienced the behaviour on Server 2012 as I was not using the GUI.
This is an excerpt from KB 2554859 describing the issue:
Unfortunately, this issue also manifests itself in Windows Server 2012, though the last bullet is slightly different.
Let’s run through the behaviour you will see and then what to do about it
This is our starting configuration. A simple setup with a single IPv4 address bound to one NIC.
Get-NetAdapter | Get-NetIPAddress | Select IPAddress, SkipAsSource
Let’s use PowerShell’s New-NetIPAddress cmdlet to add an additional IP 192.168.10.121 and specify the –SkipAsSource parameter.
New-NetIPAddress –IPAddress 192.168.10.121 –InterfaceAlias “Ethernet 2” –SkipAsSource $True
Looks OK, but we shall verify…
Get-NetAdapter | Get-NetIPAddress | Select IPAddress, SkipAsSource
So far so good! Time to change it up!
To replicate the issue, let’s now make a change to the IP we just added through the GUI, and change the subnet mask:
And when we check the SkipAsSource settings after saving the change in the GUI, we can see that the SkipAsSource flag has been lost for the IP address of 192.168.10.121
Interestingly enough if we add multiple additional IPs, each of which is set to SkipAsSource $True, and we only edit IP 192.168.10.121 in the GUI; only that specific IP loses it’s SkipAsSource flag.
We can see this below, IPs 192.168.10.121 to .125 were added all of which have SkipAsSource set to $True.
GUI is then used to edit just 192.168.10.121, and afterwards only that IP has lost its SkipAsSource flag.
At this time to please do not edit the IP configuration of a machine where SkipAsSource is used via the GUI. PowerShell can be used to configure IPs where this feature is used. If the GUI is used the SkipAsSource will be set changed for the IP(s) that were modified.
This is an example of using Set-NetIPAddress to change the PrefixLength (Subnet Mask) to /24. Note that even through SkipAsSource was not explicitly used in the Set-NetIPAddress cmdlet, the original setting was honoured
If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!
If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!
For all other areas please use the US contact point.
Thanks for the continued consolidation of this information! I keep having to come back to refresh my memory on the intricacies of the issue and your series helps greatly!
With that said, I have a question. What if you require multiple NICs (e.g. for multi-homing on multiple networks). How do you enforce outbound traffic always occurs over a specific IP/Network? Can you add the first IP of a secondary NIC with the SkipAsSource flag? Will this always be a problem for the secondary NIC (since the GUI can remove this flag for the first IP tied to it)?
Thanks for the feedback Matthew - it makes the effort worthwhile!
The SkipAsSource controls DNS registration. If your case if we have multiple NICs on a server and each is on a different subnet then we will be looking at the routing table to tell us how that traffic should be routed out.
What you may be also thinking about is what happens if I have multiple IPs on a singe NIC. How does the traffic come out in that case? In Windows 2003 the weak host model was used. So if traffic came it to an additional IP, it would return from the primary IP. In 2008+ the strong host model is used by default. That means traffic coming in to an IP will return from it. I'm not doing the topic justice, so pop weak host and strong host model into your search engine of choice and read away! Typically you will see Lync dudes/dudettes discussing this.
How about his as a minor workaround After adding or modifying the IP via the GUI, use powershell to: Set-NetIpAddress -IPAddress -SkipAsSource:$true Get-NetAdapter | Get-NetIPAddress | Select IPAddress, SkipAsSource will now show the IP skipassource changed
The Carrage Return has been removed from the above statement(??) Set-NetIpAddress -IPAddress -SkipAsSource:$true
Hi Kieran, yes there is a known issue with the TechNet comments widget at the moment. I've already reported that and the blog support team is working on this. One issue is that the formatting is not properly preserved - sorry !! Yes we can come back and
fix this with PowerShell, but you should not have to do this :( Cheers, Rhoderick
Hi Rhoderick, I'm back! Sorry I never responded to your response above, but once again I am having this very issue and once again led me to this post.So my question above is the same, but in this case I have multiple NICs though they have IPs all for the same network. But I have a situation where the server is choosing to use one of the IPs (main IP on NIC2) for outbound traffic to one system local to its site/subnet, but it chooses to use a different IP (main IP on NIC1) for outbound traffic to a system on a different subnet. Note: NIC2 has the DNS registration checkbox UNCHECKED... basically using the NIC2 to get around the skipassource/netsh/hotfix chaos for the DNS registration issue but now it's a flat out routing issue.I'm not entirely sure this is a routing issue because both NICs have the same IP subnet. But one of the systems in question is expecting traffic to come from the "main IP" of the sending server, but because the sending server is choosing the wrong source address, access is being denied. This is driving us batty.I would imagine "skipassource" is not just a DNS function but more for preventing an IP from being used as a source address, period. At least that's what I would think based on the name "skip as source". Any ideas??Also, have we gotten any information as to why this is still an issue with 2012 R2? Do we know when MSFT is going to actually build this functionality into the GUI itself vs. using powershell/netsh? Expecting administrators to only use the command line options to get around a lacking of the GUI can't be a long term solution, can it?
Hi Matthew,Have you seen this:http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspxCheers,Rhoderick
If the GUI clearing out SkipAsSource issue is still present in Windows Server 2012 R2 can you please ask for a support article to be created and a fix created? Since there are no articles that discuss this on the Microsoft Support site one would assume
the issue had been fixed. Thanks.
I came across this issue recently on a 2012 R2 machine that had a management NIC on a separate, private subnet alongside its production NIC. The server, when pinging itself, would resolve the management NIC. I tried the PowerShell method described above,
which did fix the issue but also presented a new one: now traffic that was supposed to route over the management NIC (such as backup traffic) was now trying to route over the production NIC. In addition, the management NIC became automatically joined to the
domain, which was not desirable.
I did confirm that, after configuring through PowerShell and changing the management NIC settings through the GUI, the skipassource flag was automatically reverted to $false.
What I wound up having to do was manually force a higher metric on the management NIC. This resolved the issue without disrupting backup routing.
Has there been any progress with MSFT on allowing this to be more gracefully managed through the GUI?
I'll ask around and see if there is an update that I can share Myles.