0

I'm sorry to be unclear... I will try to rephrase the problem. I work in a school as IT-administrator and I'm not a specialist, but try to make the best out of it. I hope you guys have a little patience with me :-)

To see my network situation click here, (since I'm a newbie, I'm not allowed to post images in my posts). The red line is the problem. When I ping from the win7 clients to the win2003 server's FQDN, it randomly picks nic1, 2 or 3. (because they are like that in the DNS of Domain X). But I only get answer when it chooses NIC1 (with GW)

Is adding GW 172.21.0.254 to NIC 2 and GW 172.22.0.254 to NIC3 the right solution to solve this problem? (I googled around alot and all sites advice me to not have more than 1 gateway on a server)

So basically, I'm looking for a solution that my win7 clients can access the FQDN for my win2003 server all the time.

Here is the routing table (route print) from the 2003 server

IPv4 Route Table

Interface List

0x1 ........................... MS TCP Loopback interface

0x10003 ...00 0c 29 3f df 49 ...... Intel(R) PRO/1000 MT Network Connection #2

0x10004 ...00 0c 29 3f df 3f ...... Intel(R) PRO/1000 MT Network Connection #3

0x10005 ...00 0c 29 3f df 53 ...... Intel(R) PRO/1000 MT Network Connection

===========================================================================

===========================================================================

Active Routes:

Network Destination Netmask Gateway Interface Metric

      0.0.0.0          0.0.0.0     172.20.0.254       172.20.0.6     10

    127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1

   172.20.0.0      255.255.0.0       172.20.0.6       172.20.0.6     10

   172.20.0.6  255.255.255.255        127.0.0.1        127.0.0.1     10

172.20.255.255 255.255.255.255 172.20.0.6 172.20.0.6 10

   172.21.0.0      255.255.0.0       172.21.0.6       172.21.0.6     10

   172.21.0.6  255.255.255.255        127.0.0.1        127.0.0.1     10

172.21.255.255 255.255.255.255 172.21.0.6 172.21.0.6 10

   172.22.0.0      255.255.0.0       172.22.0.6       172.22.0.6     10

   172.22.0.6  255.255.255.255        127.0.0.1        127.0.0.1     10

172.22.255.255 255.255.255.255 172.22.0.6 172.22.0.6 10

    224.0.0.0        240.0.0.0       172.20.0.6       172.20.0.6     10

    224.0.0.0        240.0.0.0       172.21.0.6       172.21.0.6     10

    224.0.0.0        240.0.0.0       172.22.0.6       172.22.0.6     10

255.255.255.255 255.255.255.255 172.20.0.6 172.20.0.6 1

255.255.255.255 255.255.255.255 172.21.0.6 172.21.0.6 1

255.255.255.255 255.255.255.255 172.22.0.6 172.22.0.6 1

Default Gateway: 172.20.0.254

===========================================================================

Persistent Routes:

None

Thank's

Thierry.

Thierry
  • 11
  • 1
  • 1
    Providing IP addresses of all the relevant network interfaces on the servers, clients, routers, etc, would go a _long_ way toward making this answerable. – Evan Anderson Nov 10 '12 at 22:54
  • You've said a lot but you haven't actually described what the problem is, that I can tell. You've described how things are behaving now but you haven't said why that's a problem for you and you haven't described how you want things to behave. – joeqwerty Nov 11 '12 at 00:39
  • 1
    Can you run `route print` on the server and post that? – gravyface Nov 12 '12 at 22:38
  • On the meanwhile, I found a way to make my service connect through the IP-adres instead of the FQDN, so I have a workaround. But I'm still interested in the solution because I might need it later. So I posted the routing table in the original post. (it was too big to paste in a comment) – Thierry Nov 17 '12 at 19:56

2 Answers2

1

In the current setup, NIC1 is the only interface that could possibly respond to the request, because the routing table on the server only knows how to get back to the 192.168.0.X network by going through a gateway connected to that interface.

Adding a gateway to the other interfaces should alleviate the problem. If it doesn't, I would configure the services on the network in such a way that hosts from 192.168.0.X can only reach the server through NIC1.

EDIT:

Also, consider the effects of uRPF:

"Packets with source addresses that could not be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source."

Brian
  • 41
  • 3
  • yes, I know adding the gateway solves my problem, but can give problems on my router..., so not really what I should do... But thank's for the input !!! – Thierry Nov 18 '12 at 19:15
1

Likely the problem is the routing decisions being made by the win2003 server. route print from a command window will give you the routing table. I'm betting that the ping is making it to the server, but the server has no route to respond.

Try this on the server:

route add 192.168.0.0 mask 255.255.255.0 172.20.0.254 IF 1

This will add a static route to direct all traffic destined for the 192.168.0.0/24 network to go back via the working interface. Assuming that it is actually interface 1.

gravyface
  • 13,957
  • 19
  • 68
  • 100
Ryan
  • 912
  • 6
  • 12
  • Since the server only has one gateway assigned, he shouldn't have to add a static route (unless of course there's static routes assigned already). – gravyface Nov 12 '12 at 22:37
  • Indeed no static routes for now. Adding the route doesn't effect the problem. Still no reply from nic 2 and 3 – Thierry Nov 18 '12 at 19:16