Windows 2000 Not Routing Correctly

[Matt]

Hello,
I have a windows 2000 machine with 3 network cards in it... configured
as follows:

CARD A: 63.174.244.x (ip masked)
CARD B: 192.168.5.19
CARD C: 10.200.1.89

Everything works fine on this. I never have problems if I am trying to
access the machine from another machine directly connected to the
network (ie another machine on the 63.174.244.x block). However, coming
from any other block to the 63.174.244.x address is hit and mis. I'm
guessing it's a windows routing issue, but would like to resolve this.
Pings and any attempt to contact services on the machine will stop
responding for moments at a time.

The routing table looks like this:
C:\Documents and Settings\Administrator>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000004 ...00 0c 41 20 f3 a1 ...... Linksys LNE100TX(v5) Fast Ethernet
Adapter
NDIS5 Driver
0x3000005 ...00 0c 41 20 f2 bb ...... Linksys LNE100TX(v5) Fast Ethernet
Adapter
NDIS5 Driver
0x6000003 ...00 a0 c9 fb 38 b1 ...... Intel 82558-based Integrated
Ethernet with
Wake on LAN
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.200.1.1 10.200.1.89 1
0.0.0.0 0.0.0.0 63.174.244.B 63.174.244.A 1
0.0.0.0 0.0.0.0 192.168.5.1 192.168.5.19 1
10.200.1.0 255.255.255.0 10.200.1.89 10.200.1.89 1
10.200.1.89 255.255.255.255 127.0.0.1 127.0.0.1 1
10.255.255.255 255.255.255.255 10.200.1.89 10.200.1.89 1
63.174.244.0 255.255.255.0 63.174.244.A 63.174.244.A 1
63.174.244.A 255.255.255.255 127.0.0.1 127.0.0.1 1
63.255.255.255 255.255.255.255 63.174.244.A 63.174.244.A 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.5.0 255.255.255.0 192.168.5.19 192.168.5.19 1
192.168.5.19 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.5.255 255.255.255.255 192.168.5.19 192.168.5.19 1
224.0.0.0 224.0.0.0 10.200.1.89 10.200.1.89 1
224.0.0.0 224.0.0.0 63.174.244.A 63.174.244.A 1
224.0.0.0 224.0.0.0 192.168.5.19 192.168.5.19 1
255.255.255.255 255.255.255.255 192.168.5.19 192.168.5.19 1
Default Gateway: 10.200.1.1
===========================================================================
Persistent Routes:
None

A - local machine
B - default router gateway.

I'm not entirely sure why this routing table is so @#$@#$ complex.
Doing the same on any of my linux machines is nice and simple... 3 lines
for 3 interface cards.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
63.174.244.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default orion.chilitech 0.0.0.0 UG 0 0 0 eth0


But that's besides the point... so my theory is that it's the routing
table screwing something up and being unable to send packets back out
the network card... or for some reason the machine is trying to send the
responce back out the wrong default gateway.. which of course won't
work... what can I do to resolve this?

 

[Phillip Windell]

Here's what I would do with it:

#1. Clear the Routing Table with this command from a command line...
C:\> Route -f

#2. Check the Network settings of each Interface. Two of them should have a
blank Default Gateway and *only* one should have a Default Gateway. But if
it is a "closed system" then it is fine if there are no DFGs at all.

#3. Reboot the machine. The Routing Table will rebbuild when the
interfaces are activated.

At this point your Routing Table will be clean and pure like the wind driven
snow. whatever your problem is, it certainly won't be any rogue entries in
the Table. You will have a cleaner slate to start troubleshooting from.

Since all your networks, as far as I can see, are all "Directly Connected
Networks" from the perspective of this Router there should *not* be any need
for any "static routes" to be entered anywhere,.....at least not on this
Router. Now if you have a Firewall Device "dangling" off of one of these
subnets, then it will need static routes entered into it,....but let's wait
and deal with that when we get there.

 

[Guest]

Matt

You didn't state how your wired, or if you had and routers interconnecting the different nets together. I suspect your facing either a pathing issue due to the routers Route tables and/or the systems own routing services (RIP or OSPF which are supplied with Windows or other add-on route protocol {Cisco})

If your able to, ping each servers NIC IP address from a station which is directly connected to the same wire the servers' NIC is located on (no network routing). If you can ping each locally you've isolated down your problem to route path you have been trying to use. This then gets into the pathway the connection needs to go through. If you are accessing the server "coming from any other block to the 63.174.244.x " is this net different than the other IP addresses you listed

CARD A: 63.174.244.x (ip masked
CARD B: 192.168.5.1
CARD C: 10.200.1.8

Or, within one of these nets (or subnets

Then are you crossing a router (or Firewall/Proxy) then your issue is the device in between and/or the servers dynamic route reply to the router device (RIP or RIP2) once you have connected to the server the first time. This is were you may nned to set a static route entry into the servers IP stack [run ROUTE again and use the ADD function to add the network & mask]

If the server is expected to act as a router did you enable it? and did you enable RIP2or OSPF services? dependingon what your doing you may need one of them

Frankly I would not recommend running the server with routing enabled (IP crossing across the NIC's) as it opens ou up to other problems and issues (i.e. security).

 

[Matt]

Hi,
Thanks for your info.
CARDB --> no gateway
CARDC--> behind a pix
CARDA--> behind a router.

When the system becomes unreachable on the 63.174.244.x address, it is
still reachable via a computer on the 63.174.244.x network that is
connected to the same switch, but it becomes unreachable from any other
subnet (ie going through a router).

I have reason to believe it is not the router, as there are around 200
other systems on this same network block not having issues. Of course,
all of them have one network interface on them.

The server is not expected to do any routing.

I understand about running route add and adding in the netblock and
where to go, but that seems like a hack/patch rather then a fix.
Since, yes that will fix MY problem, but in general, it seems like this
means the route stack is broken in windows, if it can't figure out how
to get back out the way it came in.

 

[Matt]

Ok.
the 192.x block has no gateway.. that just has some radios on it
(wireless services) that are polled.
The 10.200.x block has a PIX firewall on it... but there is no need to
go out that way.. there is, however, a default gateway in that interface.
The 63.174.244.x block is connected to a router, and has a default
gateway.... it needs to get to the internet.

So what you are telling me is to remove the default gateway from the
10.200.x block and just leave the gateway in the 63.174.244.x block?

yes, I would think this will fix the problem. However, why is windows
having an issue trying to figure out which interface to send responce
traffic back out?

 

[Phillip Windell]

So what you are telling me is to remove the default gateway from the
10.200.x block and just leave the gateway in the 63.174.244.x block?

Yes, that is correct.

yes, I would think this will fix the problem. However, why is windows
having an issue trying to figure out which interface to send responce
traffic back out?

Correct the gateway thing, clear the Routing Table, Reboot the
machine,...then we'll worry about that. You may not even have that problem
anymore at that point.

 

[Matt]

Ok,
I've done this we'll see if it works. It did seem that the 10.200.x and
the 63.174.x would flop back and forth in the route statement (don't ask
me why).

On a semi-related note. I have a piece of software that sends out SNMP
polls to computers. It can do a 'global lookup' on an IP block. It
seems when I bring this computer up from a reboot I have to disable and
reenable the network cards in the right order to make the 192.168.5.x
block be ?first?. Is there anyway to specify interface startup order?

basically if I type an IP into this software like 192.168.5.13 it will
find the radio. If I just type in a community string and tell the
software to find all radios with that string, it just sits there and
says.. nope none found.. (presumably because it's going out the wrong
network interface.. and well, there aren't any radios there). If I
stop the 63 and the 10 network cards and restart them (changing order I
assume) it's all good them.

 

[Phillip Windell]

block be ?first?. Is there anyway to specify interface startup order?

1. Properties of Network Places
2. Select "Advanced" from menu at top
3. Select "Advanced Settings..." from drop down menu
4. In the upper box use the Arrows on the side to move the NIC you want to
be first to the top of the list.

 

[Guest]

I think I see your problem. If both card B & Card A strattle the router then your getting into how the Router sees the pathway to the server system. I think your Router is getting confused on the pathway back to the server depending on what is still present in the Routers cache and which interface on the server sent data out last (GW NIC)

This is not a Windows OS issue or even the TCP/IP stack on the system. Your just hitting the limits on how TCP/IP in general works with its' automation. A UNIX server would have the same problem

OK, what to do ..
Make sure you haven't added a second GW entry in the TCP/IP stack. In W2k & XP they do work unlike NT. But in this configit gets in the way

The fix is not on the server systems Route table. You need to add the server system into the Routers routing protocols services. That is not to say this server will 'Route' only to get the routers route table updates. This then allows the server and the routers within the network to know 'All the paths'. Now you do have one issue here as you need to use a vector type of routing protocol like OSPF (RIP won't work here) as the route paths need to be costed. Just add the OSPF service on the system (assuming that is your Routing protocol, if not, add the correct protocol service as needed {Cisco}). Make sure the protocol service is started and is set to autostart on restart. You may need to create the config tables for the protocol service

Assign a network rule entry so the route is via the network it came in on (one for each network). Any local outbound coonections will follow the GW entry if the target is not on any of the local nets. I assume the PIX fire wall is your GW network.

 

[Matt]

I've got that set.
192.168 first
10.200 second
63.174 third

For some reason on bootup I still need to disable the 10.200 and the
63.174 and then renable them to get stuff to go out the 192.168
interface first. BLAH!