Source IP address selection on a Multi-Homed Windows Computer

Source IP address selection on a Multi-Homed Windows Computer

  • Comments 11
  • Likes

There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection.

What is Source IP address selection?

Source IP address selection is the process by which the stack chooses an IP address.

Windows XP and Windows Server 2003 are based on the weak host model.

When a Windows Sockets program binds to a socket, one of the parameters that is passed in the bind() call is the local (source) IP address that should be used for outbound packets. Most programs do not have any knowledge of network topology, so they specify IPADDR_ANY instead of a specific IP address in their bind() call. IPADDR_ANY tells the stack that the program is going to let the stack choose the best local IP address to use;

Windows XP behavior

KB175396 - Windows Socket Connection from a Multiple-Homed Computer

The TCP/IP component of all Microsoft Windows operating systems prior to Windows Vista is based on a Weak Host model. This model gives program developers the greatest amount of leeway when they design programs that use the network and are compatible with Microsoft products. This model also puts the responsibility of the behavior of the networking program on the developers, because the developers specify how the program accesses the TCP/IP stack and responds to incoming and outgoing frames.

On a computer that has one network adapter, the IP address that is chosen is the Primary IP address of the network adaptor in the computer. However, on a multiple-homed computer, the stack must first make a choice. The stack cannot make an intelligent choice until it knows the target IP address for the connection.

When the program sends a connect() call to a target IP address, or sends a send() call to a UDP datagram, the stack references the target IP address, and then examines the IP route table so that it can choose the best network adapter over which to send the packet. After this network adapter has been chosen, the stack reads the Primary IP address associated with that network adapter and uses that IP address as the source IP address for the outbound packets.

Example:
Source supplied in the call: IPADDR_ANY
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:192.168.1.10
The chosen source NIC: Nic 1

If the program specifies a source IP address to use in the bind() call, that IP address is used as the source IP address for connections sourced from that socket. However, the route table is still used to route the outbound IP datagrams, based on the target IP address. As a result of this behavior, the source IP address may not be the one associated with the network adapter that is chosen to send the packets.

Example:
Source supplied in the call:10.0.0.10
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:10.0.0.10
The chosen source Nic: Nic 1 <- Note this is not the Nic the source IP is on.

Summary

If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter.

If the source IP is specified the adapter that is used to send the packet is the one with a route that most closely matches the target IP address and this may not be the adapter that is associated with the source IP.

Windows Vista/Windows Server 2008 behavior

Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist.

Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets.

Example:

Source supplied in the call: IPADDR_ANY
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.2.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:192.168.1.11
The chosen source NIC: Nic 1

If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.

Example:
Source supplied in the call:10.0.0.10
Target IP:192.168.1.5
Route Table:
Nic 1 - 192.168.1.10/32
Nic 1 - 192.168.1.11/32
Nic 2 - 10.0.0.10/32
Nic 2 - 10.0.0.11/32
The chosen source IP:10.0.0.10
The chosen source Nic: Nic 2 <- Note this is the Nic the source IP is on.
Note: the packet would be sent to the default gateway associated with Nic 2.

RFC 3484 and Source IP address selection

The last thing I want to talk about is RFC 3484.

Even though RFC 3484 says it only applies to IPV6 in Windows implementations IPV4 does follow the same rules when possible.

Windows Source IP V4 address selection:
Rule 1 Prefer same address (applies)
Rule 2 Prefer appropriate scope (applies)
Rule 3 Avoid deprecated addresses (applies)
Rule 4 - Prefer home addresses - does not apply to IP v4
Rule 5 Prefer outgoing Interfaces (applies)
Rule 6 Prefer matching label - does not apply to IP v4
Rule 7 Prefer public addresses - does not apply to IP v4
Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)
"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if
CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. "
This says that the IP with the most high order bits that match the destination of
the next hop will be used.
Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match
is with the destination IP address rather than the next hop IP address.

For example, consider the following addresses:

Client machine
IP Address
192.168.1.14 /24
192.168.1.68 /24
Default Gateway
192.168.1.127

The server will use the 192.168.1.68 address because it has the longest matching prefix.

To see this more clearly, consider the IP addresses in binary:

11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25)
11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26)
11000000 10101000 00000001 01111111 = 192.168.1.127
The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. Therefore, it is used for off-link communication.

SkipAsSource

There is a new twist in the source IP selection process.

Note: There are two variants of the below mentioned hotfix; one for Windows Vista / Windows Server 2008 and one for Windows 7 / Windows Server 2008 R2.

975808 All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2

2386184 IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2

After you install the hotfix discussed above, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new "skipassource" flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets.

Note: This command only works when adding an address you can’t apply it to an address already on the machine. You would need to remove it and add it again.

What about Neighbor Unreachability?

While the above process applies as described, there can be some confusion about neighbor unreachability and the related behavior that Windows will attempt to use the next available route if a specific route fails.

When the stack was rewritten for Windows Vista, work was done to provide feature parity between IPv4 and IPv6 so that there was only one networking stack and not two separate stacks as in Windows XP and Windows Server 2003. This had several benefits including making connectivity more resilient and being easier to patch in the event of a security vulnerability. Neighbor unreachability was one of these features.

There can be unexpected results, however, if you have a specific route defined and ARP connectivity to that remote router/gateway fails. For example, in Windows XP if you tried to ping the remote router/gateway and ARP failed to get a response, you would receive “destination host unreachable” and it would stop. After Windows Vista, if you performed the same action and ARP fails to get a response, Windows will mark the address as unreachable and look for another route. If no other specific route is found it will use the default gateway instead.  Assuming ARP works to the default gateway, it would then try ICMP to the remote resource and you would either get a reply or a time-out depending on whether the resource is reachable across the default gateway or not. If you are not expecting it this can lead to confusion when trying to troubleshoot a connectivity issue, assuming you even noticed there was a problem (remember this was done for resiliency reasons and if you can reach the resource over another route you may not ever know it failed). It is important to remember this only affects ARP troubleshooting and all other troubleshooting above that remains the same. Another point of confusion is that it will never fail back to the specific route but this is not true. Note - this is not to be confused with dead gateway detection.  Neighbor unreachability will continue to use ARP to find the remote router/gateway and will use it for new connections if it does become available again.

Additional Information

Default Address Selection for Internet Protocol version 6 (IPv6)

For more information about Strong and Weak Host Models, see the following Cable Guy article:

http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

The gethostbyname function has been deprecated. We recommend that you use the getaddrinfo function instead. However, we still cannot guarantee that primary IP address will be returned first.
For more information about the gethostbyname function, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/ms738524.aspx

For more information about the getaddrinfo function, visit the following Microsoft Web site:

http://msdn2.microsoft.com/en-us/library/ms738520(VS.85).aspx

- David Pracht

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://rapasasolutions01.com/26/microsoft-enterprise-networking-team-source-ip-address-selection/

  • Interesting. Very handy information to have around.

  • What would happen if you had a loopback adapter installed that had another IP assigned to it and you were to use that IP as the source. For example a /32 address assigned to the loopback that was being advertised out of both interfaces using RIP to provide resiliancy using networking protocols.

    Example:

    Source supplied in the call:10.0.0.10

    Target IP:192.168.1.5

    Route Table:

    Nic 1 - 192.168.1.10/32

    Nic 2 - 192.168.1.11/32

  • On Windows 2008 What happens in a scenario where we are using a loppback adapter to host a VIP (/32 address on the client - 10.173.48.58)that is being advertised out of both physical interfaces via RIP?

    When the calling application binds to the VIP as its prefered source IP are you saying that the traffic will look for routes only applicable for the interface the VIP is bound to? That would suggest that the trafic will blackhole as there will be no logical route off of the server for this interface

    Example config

    Loopback Ethernet adapter1

      IP Address. . . . . . . . . . . . : 10.173.48.58

    Ethernet adapter2

      IP Address. . . . . . . . . . . . : 10.171.34.107

      Default Gateway . . . . . . . . . : 10.171.34.97

    Ethernet adapter3

      IP Address. . . . . . . . . . . . : 10.171.33.107

      Default Gateway . . . . . . . . . : 10.171.33.97

  • was truly telling about your site I thank you very much ongoing follow

  • on this matter Thank you for sharing with us such a thing

  • Thank you very much for this good article.

    It finally explains nicely how this hell works on Windows and why Win2K8 behave correctly while Win3K does not in my configuration !

    Thanks again for taking time writing this stuf !

    Would like to see the same stuf for IIS6/7 : what source IP it does use for outbound connections and in which case ?

  • Introducing such a topic you'd like to congratulate you've let us know.

  • thank you very good very good article

  • What impact does binding order have on any/all of this?

  • I have a question, though given the age of this post it may not get answered.  What happens with longest prefix matching when the IP addresses have the same number of matching bits?  For example:

    11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25)

    11000000 10101000 00000001 00001111 = 192.168.1.15 (Bits matching the gateway = 25)

    11000000 10101000 00000001 01111111 = 192.168.1.127

    Which address is then chosen?  I don't see anything in this article post that takes into consideration this scenario.  Did I gloss over such information?