Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have had this server set-up:


Due to circumstances, I had to move away ip and to serverB, this worked out fine. Unfortunately, serverA and serverB cannot see each other anymore through the 200.* IP range. I figured this might be related to the netmask, which is currently set for all IPs to 255.255.255.*.

Any suggestion on what I can do to fix this?

ServerA eth0


ServerB eth0:2


Note that both serverA and serverB have multiple IP addresses in the range of 200.200.200.*.

ip ad sh output serverA

2: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0b:cd:fe:b9:98 brd ff:ff:ff:ff:ff:ff
inet brd scope global eth0
inet brd scope global secondary eth0:cp1
inet6 fe80::20b:cdff:fefe:b998/64 scope link
   valid_lft forever preferred_lft forever
1: sit0: <NOARP> mtu 1480 qdisc noop
link/sit brd


link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet scope host lo 
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:38:4b:cb:64 brd ff:ff:ff:ff:ff:ff
inet 200.200.300.100/24 brd 200.200.300.255 scope global eth0
inet brd scope global eth0:cp1
inet brd scope global secondary eth0:cp2

route -n on serverA

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 eth0 UH    0      0        0 eth0   U     0      0        0 eth0         UG    0      0        0 eth0

route -n on serverB

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
200.200.300.100 UH    0      0        0 eth0 UH    0      0        0 eth0 UH    0      0        0 eth0   U     0      0        0 eth0         200.200.300.1         UG    0      0        0 eth0
share|improve this question
Have you cleared the CAM table of your switches? – EEAA Jul 22 '13 at 19:26
What does "cannot see each other anymore" mean? Do they send ARP requests to each other? Do they get replies? – David Schwartz Jul 22 '13 at 19:34
IP address cannot be resolved anymore. So on serverA, a ping for instance does not get any response: ping doesn't work from serverA ping doesn't work from serverB – Dirk de Boer Jul 22 '13 at 19:47
And I've replaced the switches, so no records there. – Dirk de Boer Jul 22 '13 at 19:50
Well, if you want any more help, you're going to need to provide more information. Current networking configuration of both servers at the least. What OS is this? – EEAA Jul 22 '13 at 19:52

Well it's because Server A and server B have the same primary IP of according to the output you posted.

Sorry, misread the primary IP of B.

The issue is because your netmask is too narrow. Change the netmask to and they will be able to talk without a router.

share|improve this answer
No that's not true, server B has 200.200.300.100 (note the 300) as primary IP. – Dirk de Boer Jul 22 '13 at 22:03
Oh sorry I misread that. Let me updated it. It's obvious now. – Matt Jul 22 '13 at 22:04
Thanks! Do I need to change the netmask for all 200.200.200.* IP's on serverA and serverB? – Dirk de Boer Jul 22 '13 at 22:06
Hang on a min... scrap that.. – Matt Jul 22 '13 at 22:06
Actually I'm not sure. I've misread it again. I shouldn't start the morning without coffee..! haha. I think I want to delete this answer. By all means try the change in subnet mask. They will talk but they should be able to anyway... sorry I think you shouldn't have to change the subnet mask. – Matt Jul 22 '13 at 22:09

Do you mean that the subnet is set to 255.255.255.* is invalid. Give that a try. Also, make sure there are no IP address conflicts.

share|improve this answer
Checked that, no luck there. – Dirk de Boer Jul 24 '13 at 16:30

As I understand you have 2 gateways there, and now you have a discontiguous network. This mean that when sever A is sending a packet to that packet is sent to gateway, the gateway think that the is in it's local network and is looking for that ip in local network he doesn't know that the same ip range is configured on other gateways.

The same for server B when is sending packets to routing table is saying to send this packet to which goes to 200.200.300.1 which is completely from other network segment. In order to fix this you should add some static rules to your routing tables on both servers, but this is not the perfect way. the best way is to have both servers connected to the same gateway. Or to configure discontiguous network on both gateways, but here you should be careful what routing protocol you're using, because some routing protocols doesn't support discontiguous network.

In order to help you I should see you network diagram and after that I can tell you what changes will be better to implement.

share|improve this answer
You're incorrect actually. There is a route on server B " U 0 0 0 eth0" which says to just deliver it to the interface eth0. It won't hit the default route rule and won't be delivered to 300.1. – Matt Jul 25 '13 at 22:19

And what's next, the packet will come to the interface and after that what the interface will do with it. You're not right, to send the packet to the interface the server should have a destination IP. The rooting table lookup process: If the network is matched the server is looking for a route for that network, the routing table says to send the packet to which is not an interface configured ip address Since the server does not have on it's local interfaces that IP, will check the routing table again for a match. 200.200.300.1 UG 0 0 0 eth0

This is the default route, and 200.200.300.1 seems to be the gateway. U 0 0 0 eth0 This mean that the packet will be sent to default route not to interface

share|improve this answer

It's solved. On serverB I changed all subnetmasks of IPs in the range 200.200.200.* to instead of which made it all work. Thanks all for your help.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.