Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have had this server set-up:

serverA
 ip 200.200.200.100
 ip 200.200.200.101
 ip 200.200.200.102
 ip 200.200.200.103

Due to circumstances, I had to move away ip 200.200.200.102 and 200.200.200.103 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

BROADCAST=200.200.200.255
IPADDR=200.200.200.100
NETMASK=255.255.255.0

ServerB eth0:2

BROADCAST=200.200.200.255
IPADDR=200.200.200.102
NETMASK=255.255.255.0

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 127.0.0.1/8 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 200.200.200.100/24 brd 200.200.200.255 scope global eth0
inet 200.200.200.101/24 brd 200.200.200.255 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 0.0.0.0 brd 0.0.0.0

serverB:

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 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 200.200.200.102/24 brd 200.200.200.255 scope global eth0:cp1
inet 200.200.200.103/24 brd 200.200.200.255 scope global secondary eth0:cp2

route -n on serverA

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
200.200.200.105   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
200.200.200.106  0.0.0.0         255.255.255.255 UH    0      0        0 eth0
200.200.200.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         200.200.200.1     0.0.0.0         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   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
200.200.200.102   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
200.200.200.103  0.0.0.0         255.255.255.255 UH    0      0        0 eth0
200.200.200.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         200.200.300.1     0.0.0.0         UG    0      0        0 eth0
share|improve this question
1  
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 200.200.200.102 doesn't work from serverA ping 200.200.200.100 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

5 Answers 5

Well it's because Server A and server B have the same primary IP of 200.200.200.100 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 255.255.0.0 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.0? 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 200.200.200.102 that packet is sent to gateway 200.200.200.1, the gateway think that the 200.200.200.102 is in it's local network and is looking for that ip in local network 200.200.200.0/24 he doesn't know that the same ip range is configured on other gateways.

The same for server B when is sending packets to 200.200.200.101 routing table is saying to send this packet to 0.0.0.0 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 "200.200.200.0 0.0.0.0 255.255.255.0 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 200.200.200.0/24 the server is looking for a route for that network, the routing table says to send the packet to 0.0.0.0 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. 0.0.0.0 200.200.300.1 0.0.0.0 UG 0 0 0 eth0

This is the default route, and 200.200.300.1 seems to be the gateway. 200.200.200.0 0.0.0.0 255.255.255.0 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 255.255.255.255 instead of 255.255.255.0 which made it all work. Thanks all for your help.

share|improve this answer

Your Answer

 
discard

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.