Justin Durrant
asked on
Windows 2003 Routing Issue
We are having a problem with routing on the following server, 172.21.106.1 (servera). I am trying to access a share on the following server, 172.21.122.57 (serverb). When I attempt to connect to the server, the traffic is being passed over the back side interface.
From the server when I attempt to hit \\serverb\share
C:\Documents and Settings\user>netstat -an | find "122.57"
TCP 172.21.95.56:1532 172.21.122.57:139 SYN_SENT
There are no static routes for this subnet on the server, therefore the default gateway should be used to reach the 122 subnet:
C:\Documents and Settings\user>route print
IPv4 Route Table
========================== ========== ========== ========== ========== =========
Interface List
0x1 .......................... . MS TCP Loopback interface
0x10003 ...00 50 56 ac 68 72 ...... VMware PCI Ethernet Adapter
0x10004 ...00 50 56 ac 43 03 ...... VMware PCI Ethernet Adapter #2
========================== ========== ========== ========== ========== =========
========================== ========== ========== ========== ========== =========
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.21.106.248 172.21.106.1 1
10.32.8.2 255.255.255.255 172.21.106.248 172.21.106.1 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.21.95.0 255.255.255.0 172.21.95.56 172.21.95.56 10
172.21.95.56 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.106.0 255.255.255.0 172.21.106.1 172.21.106.1 10
172.21.106.1 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.106.100 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.255.255 255.255.255.255 172.21.95.56 172.21.95.56 10
172.21.255.255 255.255.255.255 172.21.106.1 172.21.106.1 10
224.0.0.0 240.0.0.0 172.21.95.56 172.21.95.56 10
224.0.0.0 240.0.0.0 172.21.106.1 172.21.106.1 10
255.255.255.255 255.255.255.255 172.21.95.56 172.21.95.56 1
255.255.255.255 255.255.255.255 172.21.106.1 172.21.106.1 1
Default Gateway: 172.21.106.248
========================== ========== ========== ========== ========== =========
Persistent Routes:
Network Address Netmask Gateway Address Metric
10.32.8.2 255.255.255.255 172.21.106.248 1
Also, bear in mind, the 106.x NIC has presedence over the back side NIC in the binding order.
Heres where things get interesting. I run a tracert to the IP, and the route is learned.
C:\Documents and Settings\user>tracert 172.21.122.57
Tracing route to serverb [172.21.122.57]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.21.106.248
2 <1 ms <1 ms <1 ms 172.21.96.248
3 1 ms <1 ms <1 ms serverb [172.21.122.57]
Now when I hit the UNC, the frontside interface is used&
C:\Documents and Settings\user>netstat -an | find "122.57"
TCP 172.21.106.1:1727 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1731 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1734 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1737 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1740 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1743 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1746 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1749 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1752 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1755 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1758 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1761 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1764 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1767 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1770 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1773 172.21.122.57:139 ESTABLISHED
Have anyone ever seen anything like this before? I need the frontside interface to be used, always. This is happening on multiple servers on this subnet (172.21.106.3). Are we missing some static routes?
Thanks!
From the server when I attempt to hit \\serverb\share
C:\Documents and Settings\user>netstat -an | find "122.57"
TCP 172.21.95.56:1532 172.21.122.57:139 SYN_SENT
There are no static routes for this subnet on the server, therefore the default gateway should be used to reach the 122 subnet:
C:\Documents and Settings\user>route print
IPv4 Route Table
==========================
Interface List
0x1 ..........................
0x10003 ...00 50 56 ac 68 72 ...... VMware PCI Ethernet Adapter
0x10004 ...00 50 56 ac 43 03 ...... VMware PCI Ethernet Adapter #2
==========================
==========================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.21.106.248 172.21.106.1 1
10.32.8.2 255.255.255.255 172.21.106.248 172.21.106.1 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.21.95.0 255.255.255.0 172.21.95.56 172.21.95.56 10
172.21.95.56 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.106.0 255.255.255.0 172.21.106.1 172.21.106.1 10
172.21.106.1 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.106.100 255.255.255.255 127.0.0.1 127.0.0.1 10
172.21.255.255 255.255.255.255 172.21.95.56 172.21.95.56 10
172.21.255.255 255.255.255.255 172.21.106.1 172.21.106.1 10
224.0.0.0 240.0.0.0 172.21.95.56 172.21.95.56 10
224.0.0.0 240.0.0.0 172.21.106.1 172.21.106.1 10
255.255.255.255 255.255.255.255 172.21.95.56 172.21.95.56 1
255.255.255.255 255.255.255.255 172.21.106.1 172.21.106.1 1
Default Gateway: 172.21.106.248
==========================
Persistent Routes:
Network Address Netmask Gateway Address Metric
10.32.8.2 255.255.255.255 172.21.106.248 1
Also, bear in mind, the 106.x NIC has presedence over the back side NIC in the binding order.
Heres where things get interesting. I run a tracert to the IP, and the route is learned.
C:\Documents and Settings\user>tracert 172.21.122.57
Tracing route to serverb [172.21.122.57]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.21.106.248
2 <1 ms <1 ms <1 ms 172.21.96.248
3 1 ms <1 ms <1 ms serverb [172.21.122.57]
Now when I hit the UNC, the frontside interface is used&
C:\Documents and Settings\user>netstat -an | find "122.57"
TCP 172.21.106.1:1727 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1731 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1734 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1737 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1740 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1743 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1746 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1749 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1752 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1755 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1758 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1761 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1764 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1767 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1770 172.21.122.57:139 TIME_WAIT
TCP 172.21.106.1:1773 172.21.122.57:139 ESTABLISHED
Have anyone ever seen anything like this before? I need the frontside interface to be used, always. This is happening on multiple servers on this subnet (172.21.106.3). Are we missing some static routes?
Thanks!
ASKER
Nope.. the subnets are different. I am not sure if netbios is being used between .95 and .122. I can say that the .95 nic has netbios set to "default". The .106 nic has "netbios over TCP\IP enabled".
I may be wrong, happened lots of time in the past, but something looks funky with your route print. Specifically the following 3:
172.21.106.100 255.255.255.255 127.0.0.1 127.0.0.1
172.21.255.255 255.255.255.255 172.21.95.56 172.21.95.56
172.21.255.255 255.255.255.255 172.21.106.1 172.21.106.1
I would check your subnet masks carefully, on both host and guest systems. Not sure what would cause that. Also where does 172.21.106.100 come from?
I would expect to see:
Destination Netmask Gateway Interface
0.0.0.0 0.0.0.0 172.21.106.248 172.21.106.1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
10.32.8.2 255.255.255.255 172.21.106.248 172.21.106.1
172.21.95.0 255.255.255.0 172.21.95.56 172.21.95.56
172.21.95.56 255.255.255.255 127.0.0.1 127.0.0.1
172.21.95.255 255.255.255.255 172.21.95.56 172.21.95.56
172.21.106.0 255.255.255.0 172.21.106.1 172.21.106.1
172.21.106.1 255.255.255.255 127.0.0.1 127.0.0.1
172.21.106.255 255.255.255.255 172.21.106.1 172.21.106.1
224.0.0.0 240.0.0.0 172.21.95.56 172.21.95.56
224.0.0.0 240.0.0.0 172.21.106.1 172.21.106.1
255.255.255.255 255.255.255.255 172.21.95.56 172.21.95.56
255.255.255.255 255.255.255.255 172.21.106.1 172.21.106.1
I agree the default gateway should look after it, but have you tried a static route as a test to force it?
route add 172.21.122.57 mask 255.255.255.255 172.21.106.248
Just as a long shot, under adapters and binding, you mention the order is correct, but also verify File & Print Sharing & TCP/IP is bound to the adapter.
172.21.106.100 255.255.255.255 127.0.0.1 127.0.0.1
172.21.255.255 255.255.255.255 172.21.95.56 172.21.95.56
172.21.255.255 255.255.255.255 172.21.106.1 172.21.106.1
I would check your subnet masks carefully, on both host and guest systems. Not sure what would cause that. Also where does 172.21.106.100 come from?
I would expect to see:
Destination Netmask Gateway Interface
0.0.0.0 0.0.0.0 172.21.106.248 172.21.106.1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
10.32.8.2 255.255.255.255 172.21.106.248 172.21.106.1
172.21.95.0 255.255.255.0 172.21.95.56 172.21.95.56
172.21.95.56 255.255.255.255 127.0.0.1 127.0.0.1
172.21.95.255 255.255.255.255 172.21.95.56 172.21.95.56
172.21.106.0 255.255.255.0 172.21.106.1 172.21.106.1
172.21.106.1 255.255.255.255 127.0.0.1 127.0.0.1
172.21.106.255 255.255.255.255 172.21.106.1 172.21.106.1
224.0.0.0 240.0.0.0 172.21.95.56 172.21.95.56
224.0.0.0 240.0.0.0 172.21.106.1 172.21.106.1
255.255.255.255 255.255.255.255 172.21.95.56 172.21.95.56
255.255.255.255 255.255.255.255 172.21.106.1 172.21.106.1
I agree the default gateway should look after it, but have you tried a static route as a test to force it?
route add 172.21.122.57 mask 255.255.255.255 172.21.106.248
Just as a long shot, under adapters and binding, you mention the order is correct, but also verify File & Print Sharing & TCP/IP is bound to the adapter.
ASKER
the question is, why is the Windows box choosing the wrong interface? I dont know. In this scenario, the remote system has not yet entered the equation, as if on the source I run a tracert prior to attempting to access the SMB share, the source Windows box follows the appropriate route and reaches the system (gateway 106.248). This removes any misconfiguration at the IP stack level. If the mask were wrong on either side, this would never work.
What should happen, the mask on the source server /24, includes the entire class C subnet 106.x, anything outside that subnet must pass through the default gateway (excluding static routes). In this case 122.x is on another subnet, which would require the gateway to be used to reach that subnet. Why the Windows server is selecting the backup interface as the first path, is not clear.
To answer your questions:
1. 106.100 is another address bound to the server, that is why you see it in the route print
2. If File and Print sharing were not bound to the correct adapter, I would never reach the share, which I can, after Windows uses the correct interface.
Thanks!
What should happen, the mask on the source server /24, includes the entire class C subnet 106.x, anything outside that subnet must pass through the default gateway (excluding static routes). In this case 122.x is on another subnet, which would require the gateway to be used to reach that subnet. Why the Windows server is selecting the backup interface as the first path, is not clear.
To answer your questions:
1. 106.100 is another address bound to the server, that is why you see it in the route print
2. If File and Print sharing were not bound to the correct adapter, I would never reach the share, which I can, after Windows uses the correct interface.
Thanks!
Agree with your logic 100%. I guess my key point was the route print looks odd. If there is a problem you may get unexpected results.
ASKER
Also, static route does not work.. but disabling the backup nic does. WTF. :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks jjdurrant.
Cheers !
--Rob
Cheers !
--Rob
is it possible they are trying to reach each other via netbios?