0

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
Dirk de Boer
  • 1
  • 2
  • 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
  • Sorry. This is Linux CentOS. I'll update my post with networking config. – Dirk de Boer Jul 22 '13 at 19:59
  • Network config added to the first post, let me know if you need any other info. Th anks!! – Dirk de Boer Jul 22 '13 at 20:03
  • can you ping the new ip from the server they are on? if yes, have you checked the arp tables on the server (arp -a) to make sure they can see each other at Layer 2? – Doon Jul 22 '13 at 20:07
  • Post the output of `$ ip ad sh` from both servers. – EEAA Jul 22 '13 at 20:15
  • And yes, from the server, they can ping their own IP address. arp -a on serverB starts with: hostname (200.200.200.101) at on eth0, what does that tell me? – Dirk de Boer Jul 22 '13 at 20:55
  • The output of `$ ip route sh` might be helpful. – Mark Wagner Jul 22 '13 at 21:45
  • @DirkdeBoer: When you see that they can't ping each other, the next thing you should do is figure out *why* they can't ping each other. Is ARP working? Are the beings being sent? Are they being received? You have to troubleshoot. – David Schwartz Jul 22 '13 at 21:53
  • Thanks David. ARP itself is working fine but not towards each other. I can only debug up to a certain level, as the network is managed by a third party. I just want to make sure that on the server configuration level all is fine before I approach them. – Dirk de Boer Jul 22 '13 at 22:09
  • Is there a 3rd device you can ping from each box? My network spidey senses are betting the 2nd box can't ping anything else on the network either. – MikeAWood Jul 23 '13 at 00:21
  • @DirkdeBoer - can you also capture the output of "route -n" on each server? – hookenz Jul 23 '13 at 03:02
  • Oh yeah, I can ping from serverA and serverB to serverC, that's no problem. I'll add the route to the first post. – Dirk de Boer Jul 23 '13 at 22:26
  • Why do you need route entries in there if they are on the same subnet? Or are they in there by default? – john Jul 24 '13 at 21:01
  • Hi John, they are in there by default, I didn't put them there. Should I change any of them? – Dirk de Boer Jul 24 '13 at 21:31
  • No, they look right. I asked for route entries just in case there was something screwy in there. Server A & B should be talking to each other. Have you fully shut down and rebooted both servers just in case? this is odd. – hookenz Jul 24 '13 at 22:24
  • I am not sure about your network topology. Are both serverA and serverB in the same broadcast domain (the same switch or directly connected switches, the same VLAN)? Or is there a router between them? – Dubu Jul 25 '13 at 09:21

5 Answers5

2

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.

hookenz
  • 14,132
  • 22
  • 86
  • 142
  • 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. – hookenz 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.. – hookenz 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. – hookenz Jul 22 '13 at 22:09
  • Wow, someone voted me up. they will talk I think but it's not the reason... forget this. – hookenz Jul 25 '13 at 22:23
0

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.

Renegade91127
  • 81
  • 2
0

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.

Dennys371
  • 9
  • 1
  • 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. – hookenz Jul 25 '13 at 22:19
0

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

Dennys371
  • 9
  • 1
0

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.

Dirk de Boer
  • 1
  • 2