Possible to connect to a SQL Server on a Different Subnet?

TeKniques

Hi,

I know pretty much nothing about SQL Server 2000, but I was wondering if it is possible to allow workstations to connect to a SQL Server on a different Subnet?

If this is possible, what are the configuration methods that must be used?

Thank you.

2lazybutsmart

I guess you'll just be stuck if you don't have a router to route the packets to the remote network (i.e., the different subnet).

Secondary IPs.... that's also possible. At the end of the day, the rules of determining what to do with the packets at layer 3 remain the same. Packets detined to remote networks go to the default gateway, or they're dropped if one isn't configured.

Why do you want such a config in the first place, if I may ask? you're not doing failover clustering? what then?

2lbs.

TeKniques

Thank you for the reply 2lbs.

Here is the situation.

A software application that is developed by the company I work for uses the MAC address of the workstation to determine the licensing and registering of the product. The MAC address is then added to the SQL server database to register and confirm the program.

There are 2 subnets on the network. XXX.XX.170.XXX and XXX.XX.171.XXX

The SQL server sits on the XXX.XX.170.XXX subnet and recently we just started incorporating clients on the other subnet. There is a router that separates the subnets and communication from both subnets is fine ie: ping, file sharing, etc. It is from the XXX.XX.171.XXX subnet that the MAC address cannot get registered with the SQL server.

So I thought it was a router configuration issue of perhaps not being able to pass the MAC address through, but isn't this standard when sending packets? I was under the impression that host MAC address and destination MAC address were both contained in the packet. Which led me to believe maybe SQL server has to be set up for multiple subnets. I read on MSDN yesterday about failover clustering, but I understood this to be used in case the first server was not reachable then look for a virtual server.

I am not sure, but maybe someone can clear it up for me or at least determine if it is the router or not.

Thanks.

2lazybutsmart

I get your point; and I think I understand the problem.

The hosts on subnet 171 send their frames to the SQL sever on subnet 170 by going through the router. As the frames traverse the router to the remote network, the router changes the destination and source MAC addresses as they exit the router interface. So the frames will actually have the router's MAC address as a source MAC address; the SQL Server MAC address as the destination MAC address; the host that sent the data in the first place's IP address as the source IP address and the SQL Sever IP address as the destination IP address. So to sum it up, frames exiting the router interface destined to the SQL server have this info:

Source MAC: Router exit interface
Destination MAC: SQL Sever
Source IP: Host that's communicating with the sever
Destination IP: SQL Sever

2lbs.

TeKniques

Thank you 2lbs. It makes perfect sense to me and a perfectly reasonable explanation as to what is happening.

So I guess the question is ... is it possible to configure the router to hold the original hosts' MAC address in the packet?

Otherwise I guess were screwed

2lazybutsmart

The packet is never changed by the router. What changes as the frame is packet-switched is it's stripped off the original frame and a new frame with the new information necessary for the packet to traverse the next hop network is put on the packet. So as far as playing around with the internal workings of packet-switching on the router isn't possible, IMO.

But before you submit to "technology-screwups" , look at the following scenarios:

1- (the easiest way out) put everyone on the same subnet and get rid of the router
2- get some sort of validator on the other subnet to submit only privelage info to the server (then MAC stuff won't be necessary). I don't know if this will be the best choice for you because I don't understand exactly how your sever processes privelages using the MAC addresses.
3-put the MAC address in the data load of the packet.

there are few other options, but I'll probably have to understand how exactly the MAC-address validation occurs on the sever

2lbs.

TeKniques

This was all excellent advice. Much obliged to you sir. We are going to implement (develop first) a licensing procedure that will work more effectively with this setup.

Thanks 2lbs, I appreciate everything you said.