2
I've added a second IPv4 address to a network adapter and Windows started to use this second IP as the default output address. Even the address beeing in a completely different subnet from the default gateway.
My default IP address is 169.254.1.38/24
. Yes, we use the auto address assigment IP range, but this is a static configured IP address and our DHCP server would assign me the same IP if I change to DHCP configuration. My gateway is at 169.254.1.1
.
I've added the 192.168.38.1/24
ip address using the 'advanced' button in the adapter properties. As soon as I close the dialog, Windows start using 192.168.38.1
as the output address when trying to reach the Internet. As our router is in another subnet it does not respond to the requests.
The output of route print
is (output was in portuguese I've translated the labels:
...
IPv4 route table
===========================================================================
Active routes:
Network address Mask Gateway addr. Interface Cost
0.0.0.0 0.0.0.0 169.254.1.1 192.168.38.1 266
...
And as soon as I remove the second IP, the Interface value of the route returns to 169.254.1.38
and everything goes back to normal.
Is there any way I can alter this route so it starts using the correct IP address? The route add
command just accepts interfaces as parameters and not IP adresses.
I'm using Windows 7 64bit.
I'm not using RFC 3927, the entire company was configured using 169.254.1/24 a long time ago, and changing things is not that easy. If I change my IPs to 192.168/16 per example, it will work fine, but using 169.254.1/24 does not. – Vargas – 2011-06-20T19:37:10.390
@Vargas The fact that it works fine when you fix the subnet mask is evidence that your IP stack is invoking its RFC 3927-related code paths. The 169.254.x.x addresses are reserved for RFC 3927 IPv4 link-local addressing. Modern IP stacks are written with that in mind. If you use those addresses, your IP stack's RFC 3927 code will automatically kick in. That's why I'm advising you to use address space correctly. RFC 1918's subnets are the right ones to use for what you're doing, not RFC 3927. 169.254.x.x is specially-handled, much like 0.x.x.x and 127.x.x.x and 224.x.x.x and 255.x.x.x. – Spiff – 2011-06-20T20:17:18.110