Cluster Configuration with Static Routes

I have  2 2008 R2 servers built in a cluster.  There are 4  network cards 3 are internal and 1 is public.  The public network card has the gateway and the rest is done via static routes.  When the cluster was built it was built on the private IP of 169 and no other network card was configured.  This private IP connects the servers to one another and the databases to one another, in addition the database is stored on a san unit which also has a 169 ip.  Those all talk no problem.  I can failover the cluster without issues everything is working.  My issue is this I have 2 other cards.  10.75.x.x are the ip's and the subnet is the same for both of these cards.  One of the 10.75 cards has internal DNS on it. They are both on the domain and if you look in the Network connections you see the domain name associated with both cards.  The public IP has this too - it's connected and  has the domain name associated with the nic card.  The 169 ip is unidentifed.    This server pulls images for xrays so you go to your browser type in the clusterd ip address it brings you to a prompt and  you type in user name and password and you can read the (Xray) images.  The problem unless I put a gateway in the 169 network card you can't read the image.  It will not load. The 169 ip's are really only for management and should not and will not be routed to everyone. I've check the routing (static routes) they are all correct.  I can't figure out what this issue could even be.  Except to rebuild the cluster with all the nic cards as they are and maybe by some miracle this will start working.  I have a 2003 clustered server built the same way same type of configuration and it's working fine.  Has anyone experianced this?
WellingtonISAsked:
Who is Participating?
 
WellingtonISAuthor Commented:
ACtually  this issue wasn't the routing at all like I origionally though.  There is an application which controls the subnet and that was set wrong.  Once the application was fix everything is working fine.
0
 
arnoldCommented:
The 169.254.x.x IP is the result of the network connected as a DHCP enabled network interface, but there is no DHCP server on that network to allocate an IP. There is no need to masquerade these.

If you look at the cluster resources, are only the 10.x.x.x as the private IP space and masquerading it is unnecessary Keep-alive network. It is the same as saying in a X room in my house I have a Book case with a special book.
The following are IPv4 Private IP space to use as one sees fit
The IPs 10.0.0.0-10.255.255.255 are private IP blocks not accessible from the internet.
172.16.0.0-172.31.255.255
192.168.0.0-192.168.255.255

Not sure whether you mean the public is the IP that has internet access or it actually has a Public IP directly exposing these servers to the outside without the protection of a firewall....

What IP does the user that accesses these system is? Is the user within the same location as these clustered servers, or is the user on a public/remote location?

look a the routing table on the active node cluster
route print or netstat -rn

Without completely understanding you network topology and the source from which access is being attempted, it is not clear what the current situation is.

When you add the default gateway to the 169.254.x.x what is the default gateway that you are adding? is it 10.75.x.1 is it a public IP?
0
 
WellingtonISAuthor Commented:
You make valid points but this isn't my issue. Perhaps I didn't explain correctly, so I'll try again.  This is a system called PACS.  It's function is to store xrays.  This system has 4 servers (2 database and 2 application servers) all connected to a SAN unit.  The San is on a private IP 169.123.x.x and the 2 application servers have 4 network card so they can communicate over the various VLANs.  There's no router inbetween and I don't want to use a nat inside.  The Private IPS are accessible to any user inside.  The public IP is nated in my firewall.  The pubic IP contains the gateway and all the private IPs do not.  I've added static routes.  The routing is correct because I can get to the application via the 10.75.x.x network and that's the cluster address too. MY issue is when I get to that application, I can not see the xrays.  It just says loading.  IF I add a gatway to the 169.123.x.x network, then I can view the XRAYS.  However, this is not the desired result.  That 169.123 is only for management.  I have this exacty setup on a 2003 server cluster attached to the same san with 4 nic and it's working 100% fine.  THe only gateway on that 2003 server is on the public IP which is natted in my firewall.  What happened is when the Cluster was built the only IP that was used was the 169.123.x.x with a gateway.  The servers were added to the network on this subnet too.    I suspect that this may be the reason I have to add a gateway to the 169.123.x.x ip.  I'm just  not sure if there's any type of workaround so I can get the data to talk on the 10.75.x.x side without having multiple Gateways.  I've check the routes and everything is correct.  So the question here is  how do I take the traffic from the 169.123 and move not route it to 10.75.x.x
0
 
arnoldCommented:
One, 169.123.x.x IP is a publicly routed IP block.
which could lead to seapage if the firewall is not properly configured to block outgoing traffic which would prevent legit attempts to access resources that are public and use that network.

depending on your routing table, access attempts to 169.123.x.x might be erroneously routed out through the public interface to the outside.

Lets take an office space as an example.
There are four rooms, and two exits and labeled as exits.
you have one room is named room1, second room2, third room3 and fourth exit.
Now people familiar with the office and your usage, when you tell me see me in the exit, they will go to the room named exit. A new person getting used to the new environment, will ask you at which exit not thinking of the room named exit0.

LAN =>>                                        169.123.x.x
||
||
 V


Intenet Bank network 169.123.x.x.

depenging on the system and the routing table it has, it may route requests that are addressed to 169.123.x.x through the outside firewall. to the wrong exit.

You could as part of your DHCP server configuration use option 249 Classless static route to push 169.123.x.x accessible via a path that does not lead to the Internet.
0
 
Seth SimmonsSr. Systems AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.